Proseminararbeit

ClouDAT

Patrick Nowak8. Juli 2015

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

Patrick Nowakpatrick2.nowak@tu-dortmund.deMatrikelnummer: 164457Studiengang: Bachelor InformatikPrufungsordnung: BPO2007

Proseminar Werkzeugunterstutzung fur sichere SoftwareThema: ClouDAT

Eingereicht: 8. Juli 2015

Betreuer: Shayan Ahmadian

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

i

ii

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 8. Juli 2015

Patrick Nowak

INHALTSVERZEICHNIS iii

Inhaltsverzeichnis

1 Motivation und Hintergrund 11.1 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Grundlagen 22.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Gefahren beim Cloud Computing . . . . . . . . . . . . . . . . . . . . 32.3 ISO 27001 Zertifikat . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 ClouDAT Framework 63.1 Cloud System Analysis Pattern . . . . . . . . . . . . . . . . . . . . . 63.2 Phase 1: Instanziierung von Cloud System Analysis Pattern . . . . . 73.3 Phase 2: Assets analysieren . . . . . . . . . . . . . . . . . . . . . . . 83.4 Phase 3: Instanziierung von Gefahren und Schwachstellen . . . . . . . 83.5 Phase 4: Risiken beurteilen . . . . . . . . . . . . . . . . . . . . . . . . 103.6 Phase 5: Instanziierung von Sicherheitsanforderungen . . . . . . . . . 113.7 Phase 6: Instanziierung von Kontrollen . . . . . . . . . . . . . . . . . 123.8 Phase 7: Generierung der Dokumentation . . . . . . . . . . . . . . . . 12

4 Related Work 144.1 CORAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 QUIRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5 Fazit 15

A Anhang 16

Literaturverzeichnis 19

iv INHALTSVERZEICHNIS

KAPITEL 1. MOTIVATION UND HINTERGRUND 1

1 Motivation und Hintergrund

Das ClouDAT Framework ist ein Open-Source-Werkzeug, welches im Projekt Clou-DAT entwickelt wurde. Das Projekt-Team besteht einerseits aus dem

”Institut fur

technische Systeme“, der”Universitat Duisburg-Essen“,

”LinogistiX“ und der

”Tech-

nischen Universitat Dortmund“.Das ClouDAT Framework soll Sicherheitsanforderungen und Sicherheitsmaßnahmenim Bereich Cloud Computing starken. Dies soll anhand einer Risikoanalyse undEinrichtung von Kontrollen geschehen. Nach der Einrichtung dieser wird ein stan-dardkonformes Dokument generiert. Im speziellen ist dieses Framework an kleineund mittelstandische Unternehmen (KMU) gerichtet, die durch das Framework alsOpenSource-Tool eine kostengunstige Hilfe zur Sicherung der Cloud Computing-Services bekommen. [Clo]Die Relevanz eines solchen Frameworks im Bereich des Cloud Computings sowieunterschiedliche Problematiken beim Cloud Computing werden durch verschiedeneUmfragen deutlich. Zum Beispiel zeigt eine Umfrage von 2014 bei Geschaftsfuhrernuber die Nutzung von Cloud Computing eine Steigerung um 16 %, von 28 % (2011)auf 44 % (2014). [KPMa] Es sind aber auch 35 % der Unternehmer kritisch und ab-lehnend gegenuber Cloud Computing. [KPMb] Grunde hierfur sind Probleme, wiedas Risiko von Sicherheitsverletzungen (39 %), Hohe Kosten fur mangelnde Flexibili-tat (32 %), Unsicherheit in Bezug auf das anwendbare Recht (32 %), UnzureichendeKenntnisse uber Cloud Computing (31 %), etc.. [Eur] Diese Ergebnisse zeigen, dassUnternehmen sich diese Technik wunschen, jedoch aufgrund von Gefahren, die indieser Ausarbeitung spater erlautert werden, noch nicht dazu bereit sind.

1.1 Aufbau der Arbeit

Zunachst soll diese Arbeit die Frage beantworten, was unter Cloud Computing ver-standen wird. Zudem soll ein Uberblick der moglichen Gefahren beim Cloud Com-puting geliefert werden. Anschließend wird das ISO 27001 Zertifikat als Sicherheits-standard zum Schutz von IT-Anwendungen vorgestellt. Darauf folgend werden dieGrundlagen des ClouDAT Frameworks aufgelistet und erklart.

2

2 Grundlagen

In den Grundlagen werden zunachst der Begriff des Cloud Computings erklart, daes einen wesentlichen Bestandteil dieser Arbeit darstellt. Anschließend werden ver-schiedene Gefahren beim Cloud Computing erlautert. Zuletzt soll in diesem Kapiteldas ISO 27001 Zertifikat vorgestellt und erklart werden, welches bei Befolgung dieGefahren beim Cloud Computing minimieren kann.

2.1 Cloud Computing

Der Bereich Cloud Computing soll anhand verschiedener Definitionen eingegrenztwerden. Einer dieser Definitionsversuche ist vom

”National Institute of Standards

and Technology“ (NIST) und wurde vom Bundesamt fur Sicherheit in der Informa-tionstechnik (BSI) ubersetzt. Dieser beschreibt Cloud Computing als ein Modell umschnell auf verschiedene Ressourcen von uberall zuzugreifen. Die Ressourcen sinddabei nicht auf den Speicher begrenzt, sondern konnen auch Anwendungen, Serversowie andere IT-Bestandteile sein. [BSI] Die Definition wird erweitert durch Service-und Bereitstellungsmodelle, die ebenfalls von der NIST definiert wurden. Bei denServicemodellen handelt es sich um Infrastructure as a Service (IaaS), Platform as aService (PaaS), sowie Software as a Service(SaaS). Die Servicemodelle unterscheidensich durch die unterschiedlichen zuganglich gemachten Ressourcen fur den Nutzer.

• Mit Hilfe des IaaS werden Ressourcen wie Datenspeicher oder Rechenleistungangeboten.Beispielsweise ist das Anbieten von mietbaren Servern einer Firma, die vor Ortbei der Firma bleiben, ein IaaS. Auf diesen Server kann uber eine Internetver-bindung von uberall zugegriffen werden, weswegen die Definition eines CloudComputing Systems erfullt wird.

• Mit PaaS konnen Anwendungen des Kunden mit Hilfe standardisierten Schnitt-stellen eingebunden werden.Dieser Service ist ahnlich zu dem des IaaS, jedoch hat hierbei der Kunde kei-nen Zugriff auf die Hardware oder auf das Betriebssystem. Somit ist PaaS furdas Erstellen von Cloud Computing Anwendungen fur einen Entwickler durchdie Vorgabe an Schnittstellen leichter, jedoch konnen diese auch durch ihreunveranderliche Art im Gegensatz zu IaaS limitierend wirken.

• SaaS ist das Servicemodell mit allen Anwendungen, welche die Cloud Compu-ting Definition erfullen.Diese konnen zum Beispiel ein Austausch von Dokumenten, Fotos oder Videossein.

KAPITEL 2. GRUNDLAGEN 3

[BSI] Diese Servicemodelle konnen unter verschiedenen Bedingungen bereitgestelltwerden. Diese Bedingungen sind in den Bereitstellungsmodellen fur eine Cloud de-finiert:

• Die Private Cloud, die fur eine Institution betrieben wird und von dieser odereiner anderen Institution organisiert wird.Auf diese kann nur durch die betriebene Institution zugegriffen werden. Dieserhoht den Aufwand der Organisation der Cloud fur den Betreiber, jedocherhalt dieser die Kontrolle uber aller Prozesse auf der Cloud.

• Die Public Cloud, die die Cloud einer großeren Gruppe/der Allgemeinheit zurVerfugung stellt.Hierbei haben zum Beispiel unterschiedliche Gruppen Zugriff auf die Cloud,wodurch es zum Beispiel zu Performance- oder Ressourcen-Problemen bei zuvielen Nutzern kommen kann.

• Die Community Cloud gibt nur Mitglieder einer Gemeinschaft von Organisa-tionen mit selbem Interesse Zugriff.Diese kann zum Beispiel als ein Zusammenschluss von verschiedenen Firmender selben Branche verstanden werden, die daruber bestimmte Prozessablaufeabwickeln. Durch den Zusammenschluss konnen die Prozessablaufe kosten-gunstiger sein.

• Die Hybrid Cloud ist ein Zusammenschluss von zwei oder mehreren der erstendrei Bereitstellungsmodelle. Der Zusammenschluss wird mithilfe von Schnitt-stellen bereitgestellt.Hierbei kann es sich zum Beispiel um ein Unternehmen mit einer Private Cloudhandeln, die aufgrund von Ressourcenknappheit mit einer Public Cloud ver-bunden wird.

[BSI]Bei der Betrachtung der Gefahren ist die Entscheidung, welche Service- und Bereit-stellungsmodelle genutzt werden, elementar. Die Servicemodelle mit Eigenleistungenwie bei IaaS zwingen den Nutzer selbst die Gefahren bei der Benutzung zu redu-zieren. Bei SaaS muss sich der Endkunde um den großten Teil der Gefahren nichtselber kummern, jedoch muss er dem Anbieter vertrauen konnen.

2.2 Gefahren beim Cloud Computing

In diesem Abschnitt sollen die Gefahren beim Cloud Computing erlautert werdenund durch Beispiele mit den Servicemodellen in Bezug gesetzt werden. Die aufgelis-teten Gefahren sind aus dem Dokument

”The Notorious Nine“ der

”Cloud Security

alliance“, die die neun Hauptgefahrenquellen aus dem Jahr 2013 veroffentlicht haben.Diese sind folgende, jeweils nach Gefahrenstufe absteigend geordnet:

1. Der Dateneinbruch, bei dem Außenstehende Zugriff auf Daten Anderer haben.Ein Beispiel hierfur ware ein SaaS in einer Public Cloud bei dem ein Kundedie privaten Fotos eines anderen Kunden einsehen kann.

4 2.2. GEFAHREN BEIM CLOUD COMPUTING

2. Der Datenverlust, bei dem die in der Cloud gespeicherten Daten aufgrundversehentlichen Loschens oder der Zerstorung des Servers geloscht werden.Dies konnte zum Beispiel ein Unternehmen mit einer Private Cloud betreffen,die an einem Ort gelagert wird und durch einen Brand zerstort wird.

3. Account oder Service Traffic Ubernahme, bei der Unbefugte durch beispiels-weise Phishing auf Accounts Anderer zugreifen konnen.Hierfur ware ein Beispiel die Community Cloud, bei der durch mangelnde Pass-wortverschlusselung einer Firma A der Account von einer anderen Firma B inder Cloud ubernommen wird. Dies ermoglicht ein Lesen der Daten der FirmaA durch Firma B.

4. Unsichere Interfaces und APIs gefahrden die Cloud, da uber diese viele Pro-zesse, wie die Authentifizierung und Verschlusselung, geregelt sind.Ein Beispiel hierfur ware eine unverschlusselte Verbindung zwischen dem Nut-zer einer IaaS und der Cloud.

5. Ein Denial of Service gefahrdet nicht die Cloud an sich, sondern hindert denZugriff auf diese.Dadurch konnen zum Beispiel die Nutzer einer Public Cloud nicht auf ihreDaten zugreifen.

6. Boswillige Insider sind ehemalige Arbeiter oder Geschaftspartner mit einemautorisierten Zugang zu verschiedenen Bereichen und der Absicht die Sicher-heit des Unternehmen negativ zu beeinflussen.Dies kann zum Beispiel in einer PaaS ein ehemaliger Mitarbeiter einer Firmasein, der absichtlich eine Sicherheitslucke in eine Anwendung eingebaut hat.

7. Der Missbrauch von Cloudservices ist die Gefahr, dass die Cloud fur illegaleAnwendungen wie einer DDoS-Attacke genutzt wird.Dies kann zum Beispiel bei einem IaaS passieren, bei dem die Cloud ubernom-men wurde um auf andere Systeme DDoS-Attacken zu starten.

8. Die unzureichende Risikoprufung stellt die Gefahr dar, dass Unternehmen dieProblematiken beim Cloud Computing nicht einschatzen oder verstehen kon-nen.Dies kann insbesondere KMU betreffen, da diese zumeist nicht die Ressourcenhaben um zusatzliche qualifizierte Einsatzkrafte einzustellen, die die Gefahrenverhindern einschatzen konnen.

9. Schwachstellen verteilter Systeme sind die Gefahren, ausgehend von einzelnenKomponenten, die nicht fur verteilte Systeme ausgelegt sind. Diese Kompo-nenten wurden fur nicht-verteilte Systeme entwickelt und konnen Sicherheits-lucken aufweisen, die vom Hersteller aufgrund der dafur nicht ausgelegten Ver-wendungsweise nicht ausgeschlossen wurden. Diese Sicherheitsprobleme kon-nen sich anschließend auf das gesamte verteilte System ausweiten.

KAPITEL 2. GRUNDLAGEN 5

Aufgrund dieser Gefahren bedurfen Cloud Computing Services besonderen Schutz.Dies ist aber fur Unternehmen schwierig zu bewerkstelligen, wie bei Punkt achtzu sehen. Auch der Kunde kann sich nicht sicher sein, inwiefern die verschiedenenGefahrenquellen des Cloud Anbieters beachtet wurden. Um fur den Kunden und denCloud Anbieter eine Sicherheitsrichtlinie zu geben, gibt es verschiedene Zertifikate.Insbesondere wird hierfur im Folgenden das Zertifikat ISO 27001 vorgestellt.

2.3 ISO 27001 Zertifikat

Die ISO (International Organization for Standardisation) sind Normen, die Regelnfur verschiedene Sachverhalte aufstellen. Bei einer Zertifizierung nach ISO-Standardwird gewahrleistet, dass die Normen vom Unternehmen oder einem Teilbereich desUnternehmens eingehalten werden. [ISO] Die ISO 27000-Reihe enthalt Standards furden Sicherheitsbereich von IT-Unternehmen oder Abteilungen. Fur das ISO 27001beispielsweise mussen die Unternehmen ein ISMS (information security managementsystem) gewahrleisten. In einem ISMS werden unterschiedliche Bestandteile einesUnternehmens durch Risikomanagementprozesse gesichert. [BHSS14] Diese Prozes-se reduzieren die Gefahren fur Cloud Computing Services, die in den NotoriousNine erwahnt worden sind. Die Zertifizierung wird durch externe Zertifizierer be-werkstelligt. Mit dem erworbenen Zertifikat wird bescheinigt, dass zum Zeitpunktder Zertifizierung eine ISMS eingefuhrt wurde oder bestand. Dies ermoglicht demUnternehmen der Offentlichkeit zu prasentieren, dass es Schutzmechanismen gegendie Gefahren beim Cloud Computing besitzt. Zudem kann sich auch der Kundebei der Wahl der Cloud nach bestehenden Zertifikaten und somit nach bestehendenSchutzmechanismen informieren.

6

3 ClouDAT Framework

Die Informationen des bisher nicht veroffentlichten ClouDAT Frameworks berufensich auf folgende Paper zum Thema ([AHG14], [BSKF11] sowie [BCG14]).Das ClouDAT Framework soll eine Hilfe fur die Zertifizierung nach ISO 27001 furKMU sein. Hierfur werden die Schwachstellen des Unternehmens gesucht und an-schließend gesichert. Aus den Ergebnissen wird anschließend eine Dokumentationerstellt die ein Bestandteil des ISMS ist. [AHG14] Wie im Phasenmodell in Ab-bildung 3.1 zu erkennen ist, hat das ClouDat Framework verschiedene Phasen, indenen verschiedene Eingaben getatigt werden sollen, die in external input zu fin-den sind. Diese Eingaben werden in im process verwendet. Im process ist auch dieEinteilung der Phasen erkennbar. Die Ergebnisse der einzelnen Phasen sind im in-put/ output zu finden. Da die Ergebnisse der vorigen Phasen fur die nachfolgendenPhasen elementar sind, sind diese auch als input zu sehen.

3.1 Cloud System Analysis Pattern

Fur die erste Phase wird ein CSAP (Cloud System Analysis Pattern) benotigt.Dies ist die Grundlage des ClouDAT-Frameworks, da durch dieses Pattern die gro-be Struktur des Unternehmens angerissen wird und Informationen fur die weiterenPhasen gesammelt werden.

Die Basis eines CSAPs ist ein UML-Modell, welches in Abbildung 3.2 zu erkennenist. Darauf ist erkennbar, dass das CSAP in drei Abschnitte unterteilt ist: das

”In-

direct System Environment“, das”Direct System Environment“ und die Cloud. Im

Abbildung 3.1: Phasenmodell vom ClouDAT Framework eingegliedert die Bereiche derEingabe und Ausgabe sowie die Phase des Frameworks. [AHG14] CASP im external inputund process sind ein Tippfehler im Paper und sollen CSAP heißen.

KAPITEL 3. CLOUDAT FRAMEWORK 7

Abbildung 3.2: UML-Modell des Grundgerustes vom CSAP [BSKF11]

”Indirect System Environment“, werden verschiedene Stakeholder zusammengefasst,

die nicht unmittelbar mit der Cloud zusammenhangen. Stakeholder sind einzelnePersonen, eine Gruppe, oder eine Organisation, die ein bestimmtes Interesse im un-tersuchten Aufbau besitzen. [BCG14] Diese Stakeholder sind zum Beispiel fur dieRegularien der Cloud als Gesetzesgeber zustandig. Die Stakeholder, die mit derCloud direkt in Verbindung stehen, sind im

”Direct System Environment“ zu finden.

Je nach Zugehorigkeit im CSAP werden die Stakeholder direkte oder indirekte Stake-holder genannt. Die direkten Stakeholder bestehen aus einem

”Cloud Provider“, der

die Grundvoraussetzungen der Cloud an einen”Cloud Customer“ liefert. Der

”Cloud

Customer“ beschaftigt”Cloud Developer“, die sich um den Betrieb der Cloud kum-

mern, und besitzt”End Customer“, die die Cloud nutzen sollen. Die Cloud selbst ist

unterteilt in: Erstens, den Ressourcenpart, bestehend aus Hard- und Software, dieeinen

”Pool“ bilden, und zweitens einen

”Service“, auf den die

”Cloud Developer“ und

”End Customer“ zugreifen konnen. Die Services sind nach den bekannten Modellen

IaaS, PaaS und SaaS unterteilt. [BSKF11]

3.2 Phase 1: Instanziierung von Cloud System Analysis Pattern

In der ersten Phase des Frameworks soll ein CSAP erzeugt und genutzt werden. Hier-fur mussen die Informationen gemaß des Grundgerustes in Abbildung 3.2 eingege-ben. Fur die Gewinnung der Informationen werden verschiedene Templates verwen-det. Zunachst werden die relevanten Informationen fur jeden direkten Stakeholderdefiniert und aufgelistet. In diesem Template werden beispielsweise die Assets derStakeholder abgefragt. Definiert sind Assets in der ISO 27001:2005 durch

”alle Din-

ge, die einen Wert fur das Unternehmen besitzen“. [fSII11] Andere Informationen,die im Template abgefragt werden, sind zum Beispiel:

”die Beziehung zu anderen

8 3.3. PHASE 2: ASSETS ANALYSIEREN

Stakeholdern“ oder”welche Motivation besteht die Cloud zu nutzen“. [BSKF11] Es

werden aber auch weitere Informationen zum Cloud Computing System benotigt.Dies sind zum Beispiel die verschiedenen Service- oder Bereitstellungsmodelle. Aberauch die Informationen zum geographischen Ort der Cloudressourcen konnen re-levant sein, falls diese sich in einem anderen Land befinden. Zuletzt mussen dieindirekten Stakeholder definiert werden, da durch diese zusatzlichen Regularien furdie Cloud entstehen konnen. Ein Beispiel wie ein entwickeltes UML-Modell fur einUnternehmen aussehen kann ist in der Abbildung A.1 im Anhang zu sehen. [BSKF11]

3.3 Phase 2: Assets analysieren

Fur die Risikoanalyse mussen die aus der ersten Phase gefundenen Assets bearbeitetwerden. Da diese nach der Eingabe zu abstrakt fur die Risikoanalyse sind werden sieverfeinert. Falls die Verfeinerung nach dem ersten Schritt nicht wirksam war, wirddieser Schritt beliebig oft wiederholt, bis das sich ergebende Asset nutzbar ist. Zu-dem wird der Ort der jeweiligen Assets als zusatzliche Information gespeichert. Imnachsten Schritt werden die Besitzer und die Beziehungen zwischen verschiedenenAssets untersucht und in ein Template eingetragen. Ein Beispiel fur ein entwickeltesTemplate ist die Abbildung A.2, die im Anhang zu finden ist. Dieses Template ist auseiner Assetsanalyse des LANFER SYSTEMHAUSES generiert worden. [AHG14]In diesem Template sind aber nicht nur die Assets und der Ort zu finden, sondernauch weitere Eigenschaften. Diese weiteren Eigenschaften sind fur die Risikoanalysewichtig, denn nach der Klausel 8.2.2.2 in ISO 27001 ist der Assetsbesitzer die Person,anhand derer die Wichtigkeit des Assets entschieden wird. [fSII11] Fur diese Informa-tionen wird wie in der Abbildung 3.1 zu sehen, das CSAP als Eingabe verwendet.Hier konnen verschiedene Teile des CSAP unterschiedliche Informationen liefern.Zum Beispiel helfen die Assoziationen im CSAP die Informationsflussrichtungen zubestimmen. Durch die Informationen uber die Informationsflussrichtungen konnendie Asset-Besitzer identifiziert werden. [AHG14] Ein Beispiel hierfur ware ein Asset,welches ein Softwaretool sein kann, das von einem Entwickler geschrieben wordenist. Da dieser Entwickler nicht der Chef des Unternehmens ist, ist dieses Asset auchnicht ihm zuzuordnen sondern dem Chef, da dieser der Besitzer der Firma und desSoftwaretools ist, und somit auch des Assets.Daruberhinaus wird das Asset mit einem CSAP-Element verknupft. Bei dem vorigenBeispiel wurde das Asset Softwaretool mit dem CSAP-Element Software verknupftwerden. Falls Verbindungen zu bestehenden Assets existieren, werden diese ebenfallseingetragen. [AHG14] Somit wird nach dem Ende der Phase eine Liste erhalten, beider alle Assets enthalten sind, sowie verschiedene Informationen uber diese.

3.4 Phase 3: Instanziierung von Gefahren und Schwachstellen

Aus der erhaltenen Assetliste der zweiten Phase kann nun eine Gefahrenanalyse er-stellt werden. Fur diese Gefahrenanalyse wird jedes Asset analysiert und auf diemoglichen Gefahren und Schwachstellen getestet. Die Gefahren, die analysiert wer-den, sind zum Beispiel die in der Einleitung erwahnten Gefahren der CSA. Diesewurden durch weitere Gefahrenquellen erweitert. Die Schwachstellen sind als die Si-

KAPITEL 3. CLOUDAT FRAMEWORK 9

cherheitslucken zu verstehen, welche zu einer Gefahr fuhren konnen. Eingeordnetsind diese Kategorien in:

”Vertraulichkeit, Integritat und Verfugbarkeit“. [AHG14]

Um die Gefahren fur die Assets zu erkennen werden TP (Threat Pattern) verwen-det. TP sind Pattern, deren Struktur mit Hilfe eines UML Meta-Modells definiertwurden. [AHG14] Die TP sollen dabei die Assets aus der Liste der zweiten Phase mitmoglichen Gefahren verknupfen. Um eine Erleichterung fur die Nutzer zu erreichen,die voraussichtlich nicht alle Gefahren kennen konnen, ist ein Katalog zum ClouDATFramework beigelegt. In diesem sind bestehende TP vorhanden, die aus Ergebnis-sen aus den Werken [HN08], [NA09], [All11] und den Notorious Nine erstellt wordensind. Dieser Katalog kann sowie die folgenden anderen Kataloge beliebig erweitertwerden. [AHG14] Die Gefahrenanalyse kann in zwei Schritte unterteilt werden. Imersten Schritt werden die verschiedenen Gefahren identifiziert und im zweiten furdie folgenden Phasen aufbereitet.Der grundsatzliche Aufbau eines TP ist ein Standardtext, mit verschiedenen Platz-haltern. Fur die Platzhalter konnen der Name des Assets oder der CSAP-Instanzeingebaut werden. Ein Beispiel fur ein TP ist

•”Unavailability of [cloud element] for [all end customer and cloud customer]“.

[AHG14]

Im ersten Schritt, der Identifizierung von Gefahren und Schwachstellen werden hier-bei die passenden TP zu den Assets gesucht. Dabei wird in den Platzhalter, dieanhand der Umklammerung zu erkennen sind, vom ClouDAT Framework das pas-sende Asset oder die passende CSAP-Instanz eingebaut. [AHG14] Der Einbau derAssets durch das ClouDAT Framework ist als eine Erleichterung fur den Kundenzu sehen, da durch diesen automatischen Prozess Fehlentscheidungen durch denKunden unterbunden werden. Durch die Moglichkeit der Erweiterung des Katalogserhalt der Nutzer die Option eigene Entscheidungen bei der TP-Wahl zu fallen.Nach dem die Gefahren der jeweiligen Assets gefunden wurden werden die zuge-horigen Schwachstellen gesucht. Um diese zu finden existiert ein weiterer Katalogim ClouDAT Framework. Dieser Katalog hat die TP mit daraus resultierendenSchwachstellen gemappt, so dass durch den Fund eines TP auch direkt die zuge-horigen Schwachstellen gefunden werden. Da aber auch Falle auftreten konnen, indenen vorhandene Kontrollen Schwachstellen verhindern, werden diese Assets mitden Kontrollen verbunden aufgelistet. Ein Beispiel hierfur ist in Abbildung A.3 imAnhang zu finden. Diese werden bis zur Dokumentation in Phase sieben nicht mehrverwendet. Fur alle anderen Assets wird das Gefahrenpotential mit einer Gefahren-und Schwachstellenstufe ermittelt. [AHG14]Im zweiten Schritt werden aus den ermittelten TPs Gefahren- und Schwachstellen-stufen definiert. Hierbei wird die Gefahr eines Angriffs auf ein Asset in die Wahr-scheinlichkeit LOW und HIGH eingeteilt. [AHG14] Die Wahrscheinlichkeiten sollendie Attraktivitat des Assets gegenuber eines potentiellen Angreifers verdeutlichen.Ein Beispiel hierfur ware eine Liste mit Passwortern, die einen Angriff wahrschein-licher macht und mit HIGH einzustufen ist.Zudem werden die zugehorigen Schwachstellen nach bestehenden Kontrollen einge-teilt. Dies geschieht in drei Stufen: L, M und H. [AHG14]

10 3.5. PHASE 4: RISIKEN BEURTEILEN

Hierbei bedeutet L, dass es fast keine Schwachstellen gibt, da diese durch die exis-tierenden Kontrollen verhindert werden. Bei der Stufe M gibt es einen Basisschutzgegen die Schwachstellen und bei H werden sie im System derzeit nicht kontrolliert.Aus diesen beiden Informationen wird in der nachsten Phase das Risiko fur das Assetbeurteilt.

3.5 Phase 4: Risiken beurteilen

Mit Hilfe der Gefahren- und Schwachstellenstufen der dritten Phase wird in derRisikobeurteilung entschieden, welche davon fur das System akzeptabel sind. DieseGrenze wird anhand eines Risikoakzeptanzwertes gezogen, der im dritten Schrittdieser Phase erzeugt wird. [AHG14]Zunachst werden im ersten Schritt die Auswirkungen der Risiken durch die jeweili-gen Assets und ihre Schwachstellen auf das Unternehmen uberpruft. Dies geschiehtmit einer Kategorisierung der Auswirkungen bei einer Schwachstelle des Assets in:

”menschlich“,

”technisch“ oder

”wirtschaftlich“. [AHG14] Beispiele hierfur sind:

• Menschlich: Die angegriffenen Assets sind E-Mails. Daraus resultierend konn-ten private Informationen uber die Mitarbeiter veroffentlicht werden.

• Technisch: Die angegriffenen Assets sind Backups der Daten. Das Loschendieser wurde als technische Auswirkung eingeordnet werden.

• Wirtschaftlich: Die angegriffenen Assets sind Rechnungen. Das verandern die-ser kann zu wirtschaftlichen Schaden fur das Unternehmen fuhren.

Mit Hilfe dieser Einteilung und den resultierenden Auswirkungen werden diese miteinem Einflusswert versehen, der die Relevanz des Risikos mit einer Einteilung ver-binden soll. Dabei ist der Einfluss bei einer eins sehr gering und steigt auf bis zurfunf, bei der das Uberleben des Unternehmens gefahrdet ist. Eine komplette Abbil-dung (A.4) dieser Tabelle befindet sich im Anhang. [AHG14]Fur eine umfassende Risikobeurteilung werden nicht nur die Auswirkungen, sondernauch das Potential mit dem eine Schwachstelle ausgenutzt werden muss benotigt.Dies wird im zweiten Schritt vollzogen. Hierfur werden die gefundenen Schwach-stellen und Gefahren der dritten Phase beurteilt. Diese werden fur diesen Schrittkombiniert, und in eine Einteilung zwischen eins und funf kategorisiert, die dieWahrscheinlichkeit eines Sicherheitsversagens angibt. [AHG14] Zum Beispiel wirdbei einer eins die Gefahrenstufe LOW und die Schwachstellenstufe L sein. Somitgibt es durch bereits bestehende Kontrollen und wenig Interesse des Angreifers eingeringes Risiko. Bei der hochsten Wahrscheinlichkeit die als funf angegeben ist wirddie Gefahrenstufe HIGH und die Schwachstellenstufe H sein. Somit gibt es ein In-teresse des Angreifers an dem Asset, welches durch keine Kontrollen geschutzt wird.Die komplette Tabelle ist in Abbildung A.5 im Anhang zu finden.Aus den Ergebnissen der beiden ersten Schritte soll nun im dritten Schritt ein er-warteter Risikowert ermittelt werden. Hierfur wird fur jedes Asset der Einflusswertauf das Unternehmen mit der Wahrscheinlichkeit eines Sicherheitsversagens multi-pliziert. [AHG14] Diese Werte werden in einer aus dem ISO 27005 Standard

”security

KAPITEL 3. CLOUDAT FRAMEWORK 11

risk evaluation matrix“ [fSII11] eingesetzt. Daraus wird ein Risikoakzeptanzwert er-mittelt, der die Grenze zwischen akzeptablen Risiken und Risiken die minimiertwerden sollen andeutet.Mit Hilfe des ermittelten Risikoakzeptanzwertes wird im vierten und letzten Schrittder Phase uberpruft, ob der erwartete Risikowert aus dem zweiten Schritt tatsach-lich kleiner als der ermittelte Risikoakzeptanzwert ist. Wenn dies nicht der Fall ist,muss entschieden werden wie dieses Risiko behandelt werden soll. Die Reihenfolge,nach der diese Risiken minimiert werden sollen, wird durch die Hohe des erwartetenRisikowertes bestimmt.Fur die Behebung gibt es nach der ISO 27001 folgende vier Moglichkeiten:

1. Kontrollen aufbauen

2. Risiko akzeptieren

3. Risiko vermeiden

4. Assoziiertes unternehmerisches Risiko anderen Parteien ubergeben

[fSII11]Im ClouDAT Framework sollen die Risiken mit Hilfe von Kontrollen minimiert wer-den. Welche Kontrollen erstellt werden mussen wird in der nachsten Phase ermittelt.

3.6 Phase 5: Instanziierung von Sicherheitsanforderungen

In der funften Phase werden nur die Assets bearbeitet, die im vierten Schritt inder vierten Phase einen hoheren erwarteten Riskowert als den Risikoakzeptanwerthatten. Fur die Erstellung von Kontrollen in der sechsten Phase werden zunachstdie Sicherheitsanforderungen ermittelt. Diese Sicherheitsanforderungen sind in dieerwahnten Kategorien der Schwachstellen eingeteilt und beschreiben das Asset, wel-ches von einem Angreifer geschutzt werden soll. [BCG14] Fur die Erstellung derSicherheitsanwendungen werden SRP (Security Requirement Pattern) benutzt. DerAufbau der SRP ist fur den Nutzer ahnlich wie bei den TP. Die SRP werden mit ei-nem Standardtext und dem jeweiligen Platzhalter mit eingefugten Assets angezeigtund sind in einem Katalog im ClouDAT Framework enthalten. Die Entscheidungwelche SRP fur ein Asset verwendet werden soll wird durch ein Mapping der TPmit den SRP gefallt. [AHG14] Die Einteilung der SRP geschieht in verschiedeneDomanen. Zunachst werden die Domanen fur Software Requirement Pattern, derenAufbau fur die SRP ubernommen worden sind, verwendet: Fundamental, Informa-tion, Daten Entity, Benutzerfunktion, Performance, Flexibilitat, Zugangskontrolleund Geschaftlich. [Wit07] Speziell fur Cloud Computing werden fur das ClouDATFramework folgende weitere Domanen verwendet: Vertraulichkeit, Integritat, Ver-fugbarkeit, Authentizitat, Sicherheitsmanagement, Nachweisbarkeit, Privatsphare,Regelbefolgung und Codeunabhangigkeit. [BCG14]Ein Beispiel fur eine Aussage eines SRP ist:

•”SR 1: Bewahre die Vertraulichkeit der gespeicherten controlling Daten des

LANFER SYSTEMHAUS indem eine Offenlegung dieser gegenuber einem An-greifer verhindert wird“. [AHG14]

12 3.7. PHASE 6: INSTANZIIERUNG VON KONTROLLEN

Ein komplettes SRP mit allen Eingaben und Informationen ist im Anhang A.6 zufinden.Der Nutzen des SRP ist, dass das untersuchte System als ausreichend gesichertangesehen werden kann wenn alle Sicherheitsanforderungen erfullt werden. [AHG14]Damit dies auch eintritt werden in der nachsten Phase Kontrollen fur die unsicherenAssets eingerichtet.

3.7 Phase 6: Instanziierung von Kontrollen

Die in dieser Phase erzeugten Kontrollen sollen helfen, die Sicherheitsanforderungenzu erfullen. Fur eine Dokumentation nach dem ISO 27001 mussen die Kontrollendes ISO 27001 benutzt werden oder auf diese referenzieren. [Bec15] Diese Kontrollenkonnen zum Beispiel eine Implementierung einer Verschlusselung sein. Im ClouDATFramework werden fur die Kontrollzuweisungen CP (Control Pattern) genutzt, dieals Katalog enthalten sind und aus den ISO 27002 Standard gebildet worden sind.Im Iso 27002 Standard sind Referenzen auf die Kontrollen im ISO 27001 Standardenthalten. Zusatzlich sind im Katalog CP aus dem CSA CCM (cloud security allian-ce cloud controls matrix) vorhanden. [AHG14] In diesem Dokument werden in einerTabelle verschiedene Kontrolldomanen mit Informationen uber ihre Relevanz in ein-zelnen Bestandteilen des Systems aufgelistet. Zum Beispiel wird angezeigt welcheIT-Komponenten oder Servicemodelle fur die Kontrolldomane relevant sind. Zudemsind zu den einzelnen Kontrolldomanen die verschiedenen Kontrollen in unterschied-lichen Standards, wie auch der ISO 27001, zugeordnet. [All11]Die Struktur der CP ist durch ein UML Meta-Model spezifiziert. [AHG14] WelcheKontrollen eingebaut werden sollen wird mit Hilfe von Mappings der CP mit denbereits ermittelten SRPs entschieden. Falls verschiedene SRP mit den selben Kon-trollen behoben werden konnen, wird dies in der Ausgabe des CP erwahnt. EinBeispiel fur ein CP, welches sich auf das vorherige Beispiel eines SRPs SR 1 bezieht,ist folgendes:

•”C 1: Fur die Einhaltung der Sicherheitsanforderung SR 1, mussen die Kontrol-

len ISO 27002:2013 angewendet werden, zum Beispiel, Sicherheitsausstattung(A.11.2), Zugangskontrolle (A.9) einschließlich der Kontrollen gemaß unseremmapping, zum Beispiel Personalsicherheit (A.7).“ [AHG14]

Nach der Einrichtung der Kontrollen muss uberpruft werden, ob diese auch wirksamsind. Hierfur wird die vierte Phase nochmal durchgefuhrt, was eine erneute Risi-kobeurteilung bedeutet. Wenn nach dieser wiederholten Beurteilung der Risikoak-zeptanzwert wieder nicht erreicht wird, muss entschieden werden ob die Kontrollenmodifiziert werden mussen oder zusatzliche Kontrollinstanzen vonnoten sind. Mitdem Erreichen eines Systems, bei dem alle Risiken unterhalb des Risikoakzeptanz-wertes liegen, kann die letzte Phase begonnen werden. [AHG14]

3.8 Phase 7: Generierung der Dokumentation

In der letzten Phase wird ein”Statement of Applicability“ erstellt, welches ein Teil

der ISMS Dokumentation ist. [AHG14] Ubersetzt wird die”Statement of Applica-

KAPITEL 3. CLOUDAT FRAMEWORK 13

bility“ mit der Erklarung zur Anwendbarkeit. Dieses Dokument listet die Ergebnisseder Phasen auf, um protokollieren zu konnen, welche Assets Schutzmaßnahmen be-notigten und welche Kontrollen eingerichtet worden sind.

14

4 Related Work

4.1 CORAS

CORAS ist eine modellbasierte Methode mit graphischer Reprasentation fur dieRisikoanalyse, welche auf dem ISO 31000 basiert. [LSS10] Durch eine Erweiterungnamens ISMS-CORAS kann CORAS auch fur die Dokumentation nach ISO 27001verwendet werden. [BHSS14] Jedoch haben beide Modelle keine Ausrichtung aufCloud Computing. Demzufolge werden auch spezifische Gefahren fur Cloud-Systemenicht uberpruft.

4.2 QUIRC

QUIRC ein Framework, welches wie das Framework von ClouDAT speziell auf CloudComputing ausgerichtet ist. Es wird eine Risikoanalyse anhand des Einflusses fur dasUnternehmen, sowie der Gefahren und Schwachstellen durchgefuhrt. Diese werden indie Sicherheitsziele: Vertraulichkeit, Integritat, Verfugbarkeit, Multi-Party Vertrau-en, Prufbarkeit und Nutzbarkeit eingeteilt. Fur die Erkennung der Gefahren wirdSTRIDE von Microsoft verwendet. Im Gegensatz zum ClouDAT Framework wirdin diesem Framework nicht die Implementierung von Kontrollen vom Frameworkerwartet. Zudem wird keine Dokumentation fur ein ISMS ausgegeben. [SW10]

KAPITEL 5. FAZIT 15

5 Fazit

Das Thema Cloud Computing wird laut einer Umfrage unter ITK-Unternehmen imJahre 2015 als der wichtigste IT-Trend des Jahres angesehen, weswegen die Relevanzdes Tools als sehr hoch angesehen werden kann. [Bit] Viele Unternehmen sind jedoch,wie bereits in der Einleitung erwahnt, gegenuber Cloud Computing kritisch. Grundedafur sind das Risiko von Sicherheitsverletzungen sowie unzureichende Kenntnisseuber Cloud Computing. Fur diese Unternehmen kann das ClouDAT-Framework eingeeignetes Tool sein zur Erstellung eines ISMS sowie gegebenenfalls zur Zertifizierungnach ISO 27001. Durch die Benutzung der bereits bestehenden SRP, TP und CPsowie die Hilfe bei der Assetidentifizierung nach dem Erstellen eines CSAPs wirddem Unternehmen die Umsetzung eines ISMS erleichtert, ohne sich selbstandig sehrtief ins Thema Cloud Computing einarbeiten zu mussen.Der Nutzen der Zertifizierung kann in Frage gestellt werden. Laut einer Statistiksind im Zeitraum zwischen 2005 und 2011 in Deutschland 170 ISO 27001 Zertifika-te vergeben worden. [Inf] Dies zeigt, dass viele Unternehmen zu diesem Zeitpunktden Weg der Zertifizierung aus unterschiedlichen Grunden nicht genommen haben.Zudem kann in Frage gestellt werden, wie viele Endkonsumenten das Wissen uberdas ISO 27001 haben, um die Sicherheitsstandards ausgehend davon einschatzen zukonnen.Ein weiteres Problem aus Sicht der Unternehmen ist die Einhaltung des Daten-schutzes und der Sicherheitsrichtlinien des Gesetzgebers. Dieses Problem wird imFramework mit Hilfe der indirekten Stakeholder angegangen und gelost.

16

A Anhang

Abbildung A.1: Exemplarisches CSAP fur ein Bankunternehmen. [BSKF11]

ANHANG A. ANHANG 17

Abbildung A.2: Auflistung der Asset mit ihren Besitzern, den zugehorigen Orten, derzugehorigen CSAP Instanz sowie der Beziehung zu anderen Assets. [AHG14]

Abbildung A.3: Verknupfung der Assets mit existierenden Kontrollen, aufgeteilt in dieKategorien: Vertraulichkeit (C), Integritat (I) und Verfugbarkeit(A). [AHG14]

Abbildung A.4: Die Einteilung des Einflusswertes auf das Unternehmen mit der zuge-horigen Beschreibung. [AHG14]

Abbildung A.5: Die Einteilung der Wahrscheinlichkeiten eines Sicherheitsversagen mitden Gefahren-(TL.) und Schwachstellen(VL)stufen sowie der zugehorigen Beschreibung.[AHG14]

18

Abbildung A.6: Ein Beispiel eines SRPs zur Sicherheitsrichtlinie der Integritat der CloudCommunication mit den zugehorigen Informationen und Erlauterungen, in welchen Fallendiese genutzt werden sollen. [BCG14]

LITERATURVERZEICHNIS 19

Literaturverzeichnis

[AHG14] Azadeh Alebrahim, Denis Hatebur, and Ludger Goeke. Pattern-based andiso 27001 compliant risk analysis for cloud systems. In 2014 IEEE 1stWorkshop on Evolving Security and Privacy Requirements Engineering(ESPRE), pages 42–47, 2014.

[All] Cloud Security Alliance. The notorious nine cloud computing topthreats in 2013. https://downloads.cloudsecurityalliance.org/

initiatives/top_threats/The_Notorious_Nine_Cloud_Computing_

Top_Threats_in_2013.pdf.

[All11] Cloud Security Alliance. Csa. security guidance for critical areas of focusin cloud computing v3.0, 2011.

[BCF+13] Kristian Beckers, Isabelle Cote, Stephan Faßbender, Maritta Heisel, andStefan Hofbauer. A pattern-based method for establishing a cloud-specificinformation security management system. Requirements Engineering, pa-ges 1–53, 2013.

[BCG14] Kristian Beckers, Isabelle Cote, and Ludger Goeke, editors. A Catalogof Security Requirements Patterns for the Domain of Cloud ComputingSystems. ACM, 2014.

[Bec15] Kristian Beckers. Pattern and Security Requirements: Engineering-BasedEstablishment of Security Standards. Springer International Publishing,Cham, 2015.

[BHSS14] Kristian Beckers, Maritta Heisel, Bjørnar Solhaug, and Ketil Stølen. Isms-coras: A structured method for establishing an iso 27001 compliant in-formation security management system. In Engineering Secure FutureInternet Services and Systems, pages 315–344. Springer, 2014.

[Bit] Bitkom. Die wichtigsten trends in der itk-branche. http:

//de.statista.com/statistik/daten/studie/380843/umfrage/

die-wichtigsten-trends-in-der-itk-branche.

[BSI] BSI. Cloud computing grundlagen. www.bsi.bund.de/DE/Themen/

CloudComputing/Grundlagen/Grundlagen_node.html.

[BSKF11] Kristian Beckers, Holger Schmidt, Jan-Christoph Kuster, and StephanFaßbender. Pattern-based support for context establishment and asset

20 LITERATURVERZEICHNIS

identification of the iso 27000 in the field of cloud computing. In 2011Sixth International Conference on Availability, Reliability and Security(ARES), pages 327–333, 2011.

[Clo] ClouDAT. Cloudat projektseite. http://www.cloudat.de.

[Eur] Eurostat. Grund gegen die nutzung von cloud computing. http:

//de.statista.com/statistik/daten/studie/274143/umfrage/

umfrage-zu-den-gruenden-gegen-die-nutzung-von-cloud-computing.

[fSII11] International Organization for Standardization (ISO) and InternationalElectrotechnical Commission (IEC). Information technology - securitytechniques - information security risk management (iso/iec 27005), 2011.

[HN08] J. Heiser and M. Nicolett. Assessing the security risks of cloud computing,2008.

[Inf] TNS Infratest. Anzahl vergebener it-sicherheitssystem-zertifikate nach landern. http://de.statista.

com/statistik/daten/studie/168265/umfrage/

anzahl-vergebener-it-sicherheitssystem-zertifikate-nach-laendern.

[ISO] ISO. Iso standard. http://www.iso.org/iso/home/standards.htm.

[KPMa] KPMG. Einsatz von cloud computing in deutschen unternehmen. http://de.statista.com/statistik/daten/studie/177484/umfrage/

einsatz-von-cloud-computing-in-deutschen-unternehmen-2011.

[KPMb] KPMG. Grundeinstellung gegenuber cloud com-puting in deutschland. http://de.statista.

com/statistik/daten/studie/175463/umfrage/

grundeinstellung-gegenueber-cloud-computing-in-deutschland.

[LSS10] Mass Soldal Lund, Bjørnar Solhaug, and Ketil Stølen. Model-driven riskanalysis: the CORAS approach. Springer Science & Business Media, 2010.

[NA09] European Network and Information Security Agency. Cloud computing- benefits, risks and recommendations for information security, 2009.

[SW10] Prasad Saripalli and Ben Walters. Quirc: A quantitative impact and riskassessment framework for cloud security. In Cloud Computing (CLOUD),2010 IEEE 3rd International Conference on, pages 280–288. Ieee, 2010.

[Wit07] Stephen Withall. Software requirement patterns. Pearson Education,2007.