Sicherheitsprofil für ein SaaS Archivierungssystem

Transkript

1 Sicherheitsprofil für ein SaaS Archivierungssystem

2 CSC Deutschland Solutions GmbH Abraham-Lincoln.Park Wiesbaden Postfach Bonn Internet:

3 Inhaltsverzeichnis Inhaltsverzeichnis Teil 1: Sicherheitsanforderungen Einleitung Akteure, Objekte und Geschäftsprozesse (Use Cases) Akteure Datenobjekte im SaaS-Modell Geschäftsprozesse des SaaS Abonnenten Geschäftsprozesse des SaaS-Dienstleisters Besondere Anforderungen an die Archivierung elektronischer Daten und Dokumente Schutzbedarf für SaaS-Archivsysteme Vertraulichkeit Datenschutz Integrität Verfügbarkeit Gefährdungen für die Bereitstellung von SaaS Archivsystemen Gefährdungen der Interaktion Gefährdungen aus der anteiligen Bereitstellung virtueller und physischer Ressourcen für je verschiedene Serviceabonnenten Gefährdungen aus der Bereitstellung verschiedener Services für Endnutzer eines Serviceabonnenten Gefährdungen durch Sub-Dienstleister Sicherheitsanforderungen Teil 2: Bedrohungs- und Risikoanalyse Einleitung Bedrohungs- und Risikopotentiale Die signifikantesten Cloud Computing Bedrohungen Cloud Computing Schwachstellen Bedrohungs- und Risikoanalyse für ein Cloud Archiv Akteure Komponenten Kommunikation Subscriber Cloud Service Provider Vorgehen Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell Einleitung Sicherheitsmaßnahmen Organisatorische Sicherheitsmaßnahmen Technische Sicherheitsmaßnahmen Personelle Sicherheitsmaßnahmen Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell Einleitung Kreuzreferenztabellen für SaaS Archivsystem...84 Für die Abdeckung der Bedrohungen durch die in Teil 3 des Dokuments vorgeschlagenen Sicherheitsmaßnahmen Spoofing und Tampering für ADL, CSL, CMP und RCOL Repudiation and Information Disclosure für ADL, CSL und RCOL Denial of Service, Elevation of Privilege für CMP, RCOL und Communication SEU-ADL...92 Teil 5: Steckbriefe

4 Inhaltsverzeichnis Spoofing im Access & Delivery Layer Repudation im Access & Delivery Layer Information Disclosure im Access & Delivery Layer Denial of Service in der Kommunikation Subscriber Access & Delivery Layer Tampering im Cloud Service Layer Information Disclosure im Cloud Service Layer Tampering im Resource Control Layer Information Disclosure im Resource Control Layer Denial of Service im Resource Control Layer Elevation of Privilege im Resource Control Layer Tampering in der Cloud Management Plan Denial of Service in der Cloud Management Plane Elevation of Privilege in der Cloud Management Plane Anhang IETF Cloud Stack Abbildungsverzeichnis Abbildung 1: Komponenten einer Cloud Archiv Infrastruktur...6 Abbildung 2: Akteure im SaaS Archiv Umfeld... 8 Abbildung 3: Involvierte Systeme und Anwendungen Abbildung 4: Geschäftsaktivitäten der Endnutzer eines Archivs...12 Abbildung 5: Subscriber Administration Activities Abbildung 6: Aktivitäten des Cloud-Dienstleisters Abbildung 7: Besondere Aktivitäten des Cloud Dienstleisters im Management von Serviceabonnenten...16 Abbildung 8: Sicherheitsthemen im Kontext virtueller Datenspeicher...56 Abbildung 9: Übersicht über im SaaS Archive Modell involvierte Akteure und Komponenten...57 Abbildung 10: Sicherheitsaspekte im Resource Control (Composition & Orchestration) Layer...60 Tabellenverzeichnis Tabelle 1: Verantwortungszuordnung im Cloud Servicemodell... 5 Tabelle 2: Schutzbedarfskategorien für ein SaaS Archiv Modell...22 Tabelle 3: Bedrohungen und Sicherheitseigenschaften Tabelle 4: Neun sicherheitskritische Bedrohungen für Cloud Computing...52 Tabelle 5: Muster der Bedrohungs- und Risikosteckbriefe Tabelle 6: ALARP Graph

5 Sicherheitsanforderungen Teil 1: Teil 1: 1.1 Sicherheitsanforderungen Einleitung Software-as-a-Service (SaaS) verspricht den Kunden vor allem eine erhebliche Reduktion direkter und indirekter Kosten. Die Bereitstellung und das Management informationstechnischer Ressourcen (Hardware, Software, Lizenzen und Konfigurationsaufgaben), die heute unverzichtbarer Bestandteil und somit natürlich auch ein Kostenfaktor der Geschäftstätigkeit eines Unternehmens sind, werden an einen externen Dienstleister übertragen. Aus unternehmensinternen Fixkosten und variablen Betriebskosten werden variable Be triebskosten, deren Umfang ausschließlich durch den tatsächlichen Verbrauch bestimmt ist. Damit einher geht ein nicht zu unterschätzender Verlust an Kontrolle über organisatorische und technische Umstände unter denen Unternehmensdaten durch den SaaS Dienstleister erfasst, verarbeitet und gespeichert werden. Tabelle 1: Verantwortungszuordnung im Cloud Servicemodell1 SaaS Nutzung Serviceabonnent PaaS IaaS Nutzung Nutzung Anwendung Anwendung Daten Daten Plattform Betriebssysteme Cloud Dienstleister Anwendung Plattform Virtualisierung Daten Betriebssysteme Server Plattform Virtualisierung Speicher Betriebssysteme Server Netzwerk / Infrastruktur Virtualisierung Speicher Physische Sicherheit Server Netzwerk / Infrastruktur Speicher Physische Sicherheit Netzwerk / Infrastruktur Physische Sicherheit Ein Verlust, eine Manipulation, eine unbefugte Kenntnisnahme archivierter Unternehmensdaten durch Dritte oder auch nur eine Störung oder gar ein Ausfall des in Anspruch genommenen Service kann zu einer erheblichen Beeinträchtigung der Geschäftsfähigkeit des Unternehmens führen. Ein SaaS-Dienstleister wird aus ähnlichen Kostenerwägungen natürlich immer bestrebt sein, die von ihm bereitgestellten Services und Ressourcen mehreren Kunden anzubieten, um seinerseits profitabel arbeiten zu können. Der hieraus entstehende Interessenkonflikt lässt sich nur über eine sorgfältige Planung des 1 Quelle: Lim, I., Coolidge, E. C., Hourani, P.: Securing Cloud and Mobility CRC Press, Boca Raton 2013, S

6 Teil 1: Sicherheitsanforderungen Einsatzes von SaaS und ebenso präzise vertragliche Vereinbarungen über die Umstände sowie die Art und Weise der Nutzung der SaaS-Dienstleistung auflösen. Im Kern geht es dabei, über die Verfügbarkeit und den Leistungsgrad (Performanz) hinaus, vor allem um den Schutz und die Sicherheit von Unternehmensdaten. Davon betroffen sind sowohl Daten, die zu einem Zeitpunkt übertragen oder verarbeitet werden, wie auch Daten, die für die Dauer eines Dienstleistungsvertrages vom Dienstleister aufbewahrt (gespeichert) werden. Von einem vertrauenswürdigen SaaS-Dienstleister darf daher erwartet werden, überzeugend und nachvollziehbar darzustellen, dass er imstande und willens ist, über den gesamten Cloud Stack (siehe Abbildung 3) hinweg, bewegte und gespeicherte Daten gegen interne und externe Angreifer sowie Verlust oder Diebstahl zu schützen, Mandanten-bezogene Daten, Serviceinstanzen, -ressourcen und -konfigurationen hinreichend zu trennen sowie dem Kunden oder in seinem Auftrag agierende Dritten die Möglichkeit einzuräumen, die effektive Ausführung vertraglich vereinbarter Leistungen jederzeit zu verifizieren. Ziel des vorliegenden Dokuments (Teil eins des Sicherheitsprofils) ist, die Definition von Sicherheitsanforderungen an Archivdienstleistungen, die als Software-as-a-Service (SaaS) in einer Cloud Computing Umgebung bereitgestellt werden (siehe auch Abbildung 1). Die Spezifikation von Sicherheitsanforderungen an die darunter liegenden Cloud Computing Services, also Platform-as-a-Service (PaaS) und Infrastructure-as-aService (IaaS), sind nicht Gegenstand der Betrachtung. Gleichwohl gehen Sicherheitsvorstellungen für PaaS und IaaS als Annahmen in die Betrachtung mit ein. Aber sie bedürften einer vertieften und gesonderten Behandlung, wie beispielsweise die Bereitstellung und das sichere Management virtueller Ressourcen (Rechenkapazität, Netze und Netzkomponenten oder Speicher). Abbildung 1: Komponenten einer Cloud Archiv Infrastruktur Die Diskussion der Sicherheitsanforderungen erfolgt vor dem Hintergrund des IETF Cloud Stacks (siehe dazu auch Abbildung 3), existierender Sicherheitsstandards und Richtlinien, hier insbesondere ISO/IEC 27001, NIST SP , NIST FedRAMP, der CSA Cloud Computing Matrix und dem Eckpunktepapier des BSI Sicherheitsempfehlungen für Cloud Computing Anbieter sowie grundsätzlicher Geschäftsprozesse im SaaS-Archivdienstleistungs-Modell. 6

7 Sicherheitsanforderungen Teil 1: Im zweiten Teil des Sicherheitsprofils wird für die in eine SaaS-Lösung involvierten Akteure, Objekte und Kommunikationsverbindungen eine Bedrohungsanalyse nach dem STRIDE-Modell durchgeführt. STRIDE ist ein Akronym und steht für Spoofing (täuschen), Tampering (fälschen, manipulieren), Repudiation (abstreiten), Information Disclosure (aufdecken von Informationen), Denial of Service (Dienstverweigerung) und Elevation Privilege (eine unzulässige Erweiterung von Rechten), und wurde 2002 von Microsoft entwi ckelt. Auf dieser Grundlage wird dann exemplarisch aufgezeigt, wie eine Risikoanalyse für SaaS unter Be rücksichtigung des gesamten Cloud Computing Stack durchgeführt werden kann, sowie Restrisiken bestimmt werden können, die Gegenstand für weitere Analysen jenseits dieses Sicherheitsprofil sein sollten. Hieran anknüpfend werden technische, organisatorische und personelle Maßnahmen identifiziert und erläutert, die geeignet sind, den im zweiten Teil beschriebenen Bedrohungen angemessen zu begegnen. Anschließend werden die Maßnahmen mit einer Kreuzreferenztabelle auf die identifizierten Bedrohungen ab gebildet mit dem Ziel, die Überdeckung von Maßnahmen und Bedrohungen aufzuzeigen. 1.2 Akteure, Objekte und Geschäftsprozesse (Use Cases) Ausgangspunkt für die Erstellung des Sicherheitsprofils im SaaS Archivmodell ist die Identifikation von Ak teuren und Objekten (Daten, Informationssysteme) in einem Informationsverbund, die in die Archivierung (Speicherung) elektronischer Daten und Dokumente involviert sind, um davon ausgehend für die erfassten Objekte entscheiden zu können, welchen Schutzbedarf sie bezüglich Vertraulichkeit, Integrität und Verfügbarkeit besitzen und welche Sicherheitsanforderungen an die Bereitstellung und Nutzung des Services ge stellt werden müssen. Die Adressaten für dieses Profil sind hauptsächlich mittelständische Unternehmen, die diversen Aufbewahrungspflichten unterworfen sind und die diese Aufbewahrungspflicht durch ein externes Unternehmen über einen Cloud Service erfüllen wollen. Diese Aufbewahrungspflicht liegt in der Regel zwischen sechs und zehn Jahren. Eine deutlich längere Archivierung, wie sie etwa für staatliche Archive (beispielsweise Grundbucheinträge, Kataster, etc.) anzusetzen ist, ist nicht Gegenstand dieses Sicherheitsprofils Akteure In ein SaaS-Archivsystem sind eine Reihe verschiedener Akteure (Nutzer und IT-Komponenten) involviert (siehe auch Abbildung 2). Auf der einen Seite gibt es verschiedene Serviceabonnenten (subscriber), welche für die Speicherung ihrer Daten, die durch den Dienstleister bereitgestellten virtuellen und physikalischen Ressourcen nutzen. Darüber hinaus nehmen sie möglicherweise auch andere, unterschiedliche Anwendungen ein und desselben Cloud Computing Dienstleisters in Anspruch. 7

8 Teil 1: Sicherheitsanforderungen Abbildung 2: Akteure im SaaS Archiv Umfeld. In diesem Profil werden mehrere Akteure in einem SaaS-Archiv-Angebot betrachtet. Dazu gehören sowohl Nutzer und IT-Administratoren der Serviceabonnenten wie auch IT-Administratoren des Service Providers. Hinzu kommen, neben der Cloud Plattform und den virtualisierten Speicherressourcen, eine Reihe von Anwendungen der Abonnenten, aus denen heraus der Zugriff auf den Archivservice erfolgt. Diese Anwendungen können sowohl unternehmensinterne Anwendungen sein, wie auch SaaS Angebote desselben oder auch verschiedener Service Provider. Auf der anderen Seite steht der Dienstleister (Provider), der den verschiedenen Serviceabonnenten je verschiedene, virtualisierte und dynamisch skalierbare Speicherbereiche offeriert, die jedoch in den meisten Fällen dieselben physischen Ressourcen nutzen. Auf der Seite des Serviceabonnenten sind zunächst zwei Gruppen von Benutzergruppen an der Inanspruch nahme und der Bereitstellung der Dienstleistung beteiligt. Da sind zum einen die tatsächlichen Endnutzer und zum anderen IT-Administratoren des Serviceabonnenten, die über ein Managementinterface des Serviceproviders Nutzerkonten anlegen, nutzerspezifische Konfigurationen hinsichtlich der Zugriffsrechte auf die gespeicherten Daten sowie die Allokation zusätzlicher Speicherressourcen vornehmen. Auf der Seite des Providers sind es vornehmlich IT-Administratoren, die für die Bereitstellung der Dienst leistung sowohl beim Provider wie auch einem möglicherweise eingebundenen Dritten (Sub-Dienstleister)- die Konfiguration und das Management der bereitgestellten Ressourcen wie auch der für operativen Betrieb erforderlichen Cloud Umgebung (Soft- und Hardware, technische und organisatorische Infrastrukturen) bewerkstelligen und überwachen. Hinzu kommen mit Blick auf den IETF Cloud Stack (siehe dazu Abbildung 3) eine Anzahl von IT-Subsystemen und Anwendungen, sowohl auf der Seite des Serviceabonnenten wie des Serviceproviders, die an der Bereitstellung und der Nutzung des Service beteiligt sind. Auf der Seite des Serviceabonnenten sind dies vor allem Anwendungen oder Funktionen, aus denen heraus die Zugriffe auf die Speicherressourcen erfolgen. Administrative Funktionen auf der Seite des Serviceabonnenten werden im Allgemeinen durch Schnittstellenfunktionen auf der Cloud Managementebene, wie bspw. das Konfigurations- und Infrastrukturmanagement der Cloud Umgebung, unterstützt. 8

9 Sicherheitsanforderungen Teil 1: Das Access and Delivery Layer auf der Seite des Serviceproviders stellt Funktionen und allgemeine Infrastrukturkomponenten bereit, die dem Serviceabonnenten den Zugriff und die Nutzung des Service ermögli chen. Dazu gehören sowohl Nutzerportale wie auch Servicegateways zur Steuerung und Kontrolle der Zugriffe. So genannte Inter-Cloud Funktionen stellen Infrastrukturen und Komponenten bereit, um verteilte Ressourcen oder auch die Kommunikation mit Cloud Service Drittanbietern zu ermöglichen und zu steuern. Da die Nutzung überwiegend über das Internet erfolgt, umfasst diese Schicht im Allgemeinen auch Netz werkkomponenten, die in der Regel durch Netzprovider als beteiligte Dritte zur Verfügung gestellt werden. Das Cloud Service Layer bestimmt den Bedarf an funktionalen virtuellen und physischen Ressourcen, die für die zuverlässige Bereitstellung des Service benötigt werden, d. h.: Ressourcentyp (CPU, Arbeitsspeicher, Festplattenspeicher, usw.), Umfang der benötigten Ressourcen, Art der Bereitstellung (ausschließlich reserviert für einen Abonnenten, gemeinsam nutzbar, Transportmedien usw.), Zeitpunkt der Bereitstellung (on-demand oder in Zeitscheiben) und Dauer der Bereitstellung. Das Resource Control Layer steuert die Bindung virtueller Ressourcen hinsichtlich Zuverlässigkeit, Sicher heit und Effizienz, d. h. die Kontrolle des Zugriffs auf zugewiesene Ressourcen, die Verwaltung eines Ressourcenpools, mit dem Ziel einer effizienten Auslastung physischer Ressourcen, die Kontrolle verteilter Ressourcen über unterschiedliche Cloud Umgebungen oder Standorte, die Verfügbarkeit der Ressourcen entsprechend dem vereinbarten Servicelevel und das Servicelebenszyklus-Management. 9

10 Teil 1: Sicherheitsanforderungen Abbildung 3: Involvierte Systeme und Anwendungen Die Abbildung veranschaulicht in den Service involvierte Systeme und Anwendungen der Cloud Umgebung aus dem Cloud-Referenzmodells der IETF. Die blau eingefärbten Teile sind im ursprünglichen IETF-Cloud-Stack weiter detailliert, werden aber hier lediglich als Ressource für SaaS einbezogen und nur bei Bedarf weiter betrachtet. Das Ressource Abstraction and Virtualization Layer schließlich bildet die tatsächlichen physikalischen Komponenten auf virtuelle Einheiten (virtuelle CPUs, Speicher, Netzinfrastrukturen und -komponenten, usw.) ab und verbirgt auf diese Weise technische Details, die für den Serviceabonnenten, zumal im SaaS Modell, ohnehin kaum von Belang sind. Die Cloud Management Plane stellt Funktionen für die Administration und Überwachung des Cloud Umgebung bereit. Dazu gehören vor allem: 10 die automatische Einbindung (der Einsatz) verschiedener Cloud Komponenten auf der Grundlage von Konfigurationsdaten und Einsatzrichtlinien, die Registrierung und Verwaltung von Services,

11 Sicherheitsanforderungen Teil 1: Überwachungs- und Alarmfunktionen hinsichtlich des operativen Zustands der Cloud Umgebung, d. h. der Nutzung des Cloud Service, der Einhaltung der vereinbarten Leistungsparameter sowie des Zugriffs und des Auftretens sicherheitsrelevanter Ereignisse. Datenobjekte im SaaS-Modell Für eine Schutzbedarfs- und Bedrohungsanalyse eines Informationsverbundes zur Archivierung von Unternehmensdaten von Bedeutung sind natürlich sämtliche Daten und Informationen, die innerhalb des Informationsverbundes gespeichert sowie für die Speicherung und die Verwaltung der gespeicherten Daten benötigt werden. Für ein als SaaS ausgelegtes Archivsystem lassen sich vor allem die folgenden Datenobjekte ausmachen: Unternehmensdaten des Serviceabonnenten, die in der Cloud gespeichert werden sollen, Service-Konto-Daten des Serviceabonnenten, Konfigurationsdaten von Anwendungen und Schnittstellen(sowohl auf Nutzer- wie auf Providerseite), Konfigurationsdaten der Cloud Umgebung, Kryptografische Daten (Schlüssel und Zertifikate) für die Verschlüsselung der Kommunikation und ggf. auch für die Verschlüsselung gespeicherter Daten, Protokolle (Logs) über Zugriffe, die Nutzung, die Verfügbarkeit und die Performanz sowie sicherheitsrelevante Ereignisse und deren Behandlung, Auditberichte über die Einhaltung von Standards und Richtlinien sowie die Implementierung und Durchsetzung eines nachhaltigen und wirksamen Informations-Sicherheits-Managements. Geschäftsprozesse des SaaS Abonnenten Das beherrschende Motiv für die Nutzung einer SaaS Dienstleistung ist die Entlastung unternehmensinter ner Ressourcen. Ein als Software-as-a-Service in einer Cloud Umgebung bereitgestelltes elektronisches Archiv muss einem Nutzer des Serviceabonnenten wenigstens folgende Funktionen zur Verfügung stellen (sie he dazu auch Abbildung 4): Einen Submission Request, mit dem der Benutzer Unterlagen aus der vorgelagerten IT-Anwendung im Archiv ablegen kann. Der Submission Request sollte mit der Rückgabe einer eindeutigen Archiv objekt ID (AOID) abgeschlossen werden, die der Benutzer bei jedem weiteren Zugriff auf archivierte Daten vorlegen muss. Einen Retrieval Request, mit dem der Benutzer archivierte Unterlagen aus dem Speicher abrufen kann. Der Retrieval Request sollte neben den Identitätsdaten des Benutzers ebenso die Archivobjekt ID des Datenobjektes enthalten, auf das zugegriffen wird. Einen Search Request, mit dem ein Benutzer nach archivierten Unterlagen suchen kann. Das Suchergebnis sollte zunächst nur eine Liste mit AOIDs enthalten, die den Suchkriterien entsprechen. Einen Update Request, mit dem archivierte Unterlagen ergänzt werden können. Einen Evidence Request, mit dem technische Beweisdaten über die Integrität archivierter Unter lagen abgerufen werden können. 11

12 Teil 1: Sicherheitsanforderungen Einen Delete Request, mit dem archivierte Unterlagen gelöscht werden können. Abbildung 4: Geschäftsaktivitäten der Endnutzer eines Archivs Die Aufbewahrungsfristen elektronischer Unterlagen sind in der Regel durch gesetzliche Vorschriften bestimmt. Die technische Richtlinie des BSI TR ( beschreibt darüber hinaus Maßnahmen um den Beweiswert elektronisch signierter Unterlagen für die Dauer der Aufbewahrung zu erhalten. Bei der Nutzung von SaaS ist es von maßgeblicher Bedeutung zu entscheiden, welche Anwendungen wie in die Nutzung eingebunden werden sollen, und welche Daten wie in den Cloud Speichersystemen abgelegt werden sollen. Letzteres ist vor allem bestimmt durch die Fragen, welche Leistungsgüte für welchen Verfügbarkeitszeitraum (Dauer der Aufbewahrung) für den Zugriff auf die gespeicherten Daten benötigt wird und welche Maßnahmen zum Schutz der Daten erforderlich sind. Dabei geht es nicht nur um die Einhaltung ge setzlicher Vorschriften oder Regelungen oder dem Schutz der Daten vor unbefugter Einsichtnahme, Manipulation oder Diebstahl. Darüber hinaus ist auch die Frage relevant, wie für die Dauer der Aufbewahrung die Authentizität und maschinelle Lesbarkeit der gespeicherten Daten gesichert werden kann. Der Nutzung einer SaaS Dienstleistung vorangehen müssen daher Entscheidungen über 12 die Einordnung (Klassifikation) von Daten hinsichtlich ihres Schutzbedarfes, Zugriffsrechte auf gespeicherte Daten sowie

13 Sicherheitsanforderungen Teil 1: Anforderungen und Maßnahmen zum Schutz der Integrität und Authentizität gespeicherter Daten (siehe dazu auch Abschnitt 1.2.5). Die Sicherheit, der mittels einer SaaS Dienstleistung extern gespeicherten Unternehmensdaten, beginnt bei den Akteuren (Endnutzer und Anwendungen) des Serviceabonnenten. Eine wichtige Bedingung für die sichere Nutzung des SaaS Konzepts ist daher eine in Systematik und Durchsetzung wirksame Zugriffskontrollstrategie des Serviceabonnenten, die neben klaren Regelungen über Zugriffsberechtigungen auch Kontrollen über die Zulässigkeit der Speicherung von Daten und Kontrollen ihrer Integrität vorsieht. Die Nutzung eines SaaS Archivdienstes, erfolgt in der Regel durch eine Maschine-Maschine Kommunikation aus einer unternehmensinternen Anwendung oder einer ebenfalls als SaaS bereitgestellten Anwendung (bspw. ein CRM System) desselben oder eines anderen Cloud Service Providers (CSP). In beiden Fällen müs sen die Anwendungen in der Lage sein, aus Login-Daten eines Endnutzers maschinenlesbare Identifikations daten zu erzeugen, aus denen zweifelsfrei die Identität des Nutzers und der ihm zugewiesenen Berechtigun gen hervorgeht. Die Konfiguration der Archivfunktionen, einschließlich der Einrichtung und Verwaltung elektronischer Identitäten und Zugriffsrechte sowie von Regeln für die Zulässigkeit und Verarbeitung der zur Archivierung vorgesehenen Unternehmensdaten, erfolgt durch den IT-Administrator des Serviceabonnenten. Er benutzt hierfür im in der Regel Management-Interfaces der internen oder externen, als SaaS genutzten, Anwendungen. Abbildung 5: Subscriber Administration Activities Zur Administration der Endnutzer gehört, Nutzerkonten anzulegen, zu verändern oder zu löschen und die Rechte eines jeden Anwenders durch ein Rollen- und Identitätsmanagement zu steuern. In die letztere Aktivität ist die Konfiguration der sicheren Authentisierung (Schlüsselmanagement etc.) des Abonnenten mit inbegriffen. Darüber hinaus obliegt der IT-Administration die technische Klassifikation der zur Archivierung vorgesehenen Daten sowie die Konfiguration des regelbasierter Zugriffe auf die Anwendungen aus denen heraus die Archivierung erfolgen soll. Die Elemente SAD-0Y sind eindeutige Bezeichner für spätere Referenzen im Rahmen der Risikoanalyse. Eine wesentliche Sicherheitsanforderung an den SaaS Archivdienstleister ist vor diesem Hintergrund eine sichere Authentifikation für die Abonnenten und Mitarbeiter des Abonnenten mit Zugriff auf die Speicherressourcen. Diese muss verhindern, dass eine Eskalation von Zugriffsrechten wie auch eine Kompromittierung 13

14 Teil 1: Sicherheitsanforderungen oder Fälschung elektronischer Identitäten unbemerkt vonstatten gehen können Geschäftsprozesse des SaaS-Dienstleisters Wesentliche Herausforderung im SaaS-Archivierungskontext ist es, alle relevanten Geschäftsprozessaktivitäten abzubilden, welche die Orchestrierung sämtlicher für die reibungslose und sichere Funktion der Speicherung erforderlichen Services und Komponenten beinhalten. Dazu gehören (siehe auch Abbildung 6 und Abbildung 7): 14 eine zuverlässige Planung der für die Bereitstellung des Service erforderlichen Systeme, Komponenten und Ressourcen als Grundlage für ein nachhaltiges Kapazitätsmanagement, die sichere Konfiguration und der sichere Betrieb sämtlicher in die Bereitstellung des Service involvierten Systeme, Komponenten und Ressourcen, die sichere und zuverlässige (dynamische) Allokation Mandanten-bezogener physikalischer Ressourcen, die zuverlässige Segmentierung und Isolation Mandanten-bezogener Funktionen sowie virtueller und physikalischer Ressourcen, die Durchsetzung sicherer Authentisierungsprozesse und nachweisliche Protokollierung der Zugriffe (Nutzung), eine strikte Aufgabentrennung der in die Bereitstellung des Service involvierten Mitarbeiter und die Verhinderung einer Eskalation von Zugriffsrechten auf Systeme und Daten,

15 Sicherheitsanforderungen Teil 1: Abbildung 6: Aktivitäten des Cloud-Dienstleisters. Diese beinhalten (in der Abbildung links) die Anwendung bereit zu stellen, was die Orchestrierung involvierter Cloud Services und das Cloud-Management ebenso einschließt (beispielsweise auch die Segmentierung der physischen und logischen Ressourcen), wie auch die Verwaltung der Nutzer (rechts oben) und die Instanziierung und das Monitoring der SaaS-Anwendung umfasst. Die Elemente CSP-0Y sind eindeutige Bezeichner für spätere Referenzen im Rahmen der Risikoanalyse. der Schutz von (bewegten und gespeicherten) Daten vor Verlust, Diebstahl, unbefugter Kenntnisnahme und Manipulation, ggf. durch die Bereitstellung kryptografischer Maßnahmen und Funktionen, der Schutz von Speichermedien die Verhinderung fahrlässiger oder auch böswilliger Aktionen durch andere Mandanten, externer oder interner Angreifer, ein zuverlässiges und nachvollziehbares Konfigurations-, Change- und Update-Management, die zuverlässige Überwachung (Monitoring) und Aktualisierung von Sicherheitsmaßnahmen, die zuverlässige Erfassung und Analyse sicherheitsrelevanter Ereignisse sowie hieraus folgend die Gewährleistung unverzüglicher und angemessener Reaktionen zur Abwehr sicherheitsrelevanter Ereignisse oder Bedrohungen, die zuverlässige Überwachung des Betriebs und der vereinbarten Leistungsparameter sowie die Gewährleistung eines zuverlässigen Notfallmanagements, das imstande ist, im Falle einer Störung oder eines Ausfalls die Fortführung der Geschäftstätigkeit des Serviceabonnenten mit ggf. geringeren Ressourcen ermöglicht und darüber hinaus das System wieder in einen stabilen Zustand zu versetzen, 15

16 Teil 1: Sicherheitsanforderungen das zuverlässige Management von Sub-Dienstleistern. Abbildung 7: Besondere Aktivitäten des Cloud Dienstleisters im Management von Serviceabonnenten. Dazu zählt insbesondere das Management und der zuverlässige Schutz von elektronischen Identitäten und Zugriffsrechten, die Durchsetzung einer sicheren Authentisierung, ein zuverlässiges Konfigurations- und Update-Management sowie eine zuverlässige Löschung von Daten des Serviceabonnenten bei Vertragsende. Die Elemente CSP-0Y sind eindeutige Bezeichner für spätere Referenzen im Rahmen der Risikoanalyse Besondere Anforderungen an die Archivierung elektronischer Daten und Dokumente Authentizität elektronischer Dokumente Elektronische Dokumente unterscheiden sich von herkömmlichen Papierdokumenten vor allem durch ihre Volatilität. Elektronische Dokumente sind per se virtuell und können ohne technische Hilfsmittel weder wahrgenommen noch gelesen werden. Sie geben zunächst auch keinerlei Anhaltspunkte für ihre Integrität und Authentizität. Sie lassen sich ebenso leicht wie unbemerkt verändern und sind zudem dem Risiko aus gesetzt, dass Veränderungen in den, zu ihrer Darstellung erforderlichen technischen, Hilfsmittel ihre Verfüg barkeit behindern können2. Für die Erzielung und Erhaltung rechtlich verbindlicher Wirkungen elektroni2 Siehe hierzu auch A. Rossnagel, S. Fischer-Dieskau, S. Jandt, M. Knopp: Langfristige Aufbewahrung elektronischer Dokumente, Band 17 der Reihe Der elektronische Rechtsverkehr, 1.Auflage, Nomos-Verlag, 2007, BSI Technische Richtlinie Vertrauenswürdige elektronische Langzeitspeicherung, Version 1.0 vom , abrufbar unter: und Zimmer, W., Langkabel T., Hentrich C.: ArchiSafe Legally Compliant Electronic Storage, IT Professional, July/August 2008, pp

17 Sicherheitsanforderungen Teil 1: scher Dokumente sind jedoch gerade der Nachweis der Unversehrtheit (Integrität) und der Urheberschaft (Authentizität) von entscheidender Bedeutung 3. Im allgemeinen Sprachgebrauch wird der Begriff Authentizität häufig mit der Eigenschaft assoziiert, aufgrund erfüllter (oder auch nur erfüllbarer) Tatsachen oder Ereignisse akzeptabel oder glaubwürdig zu sein. Als authentisch gilt demnach ein Objekt, wenn es aufgrund nachvollziehbarer Tatsachen oder Ereignisse die Wahrnehmung des Objektes mit seinem Wesen, seiner Bestimmung in Übereinstimmung befunden werden kann4. Die Behauptung oder Annahme der Authentizität elektronischer Dokumente ist somit vornehmlich eine Folgerung, die aus bekannten und nachvollziehbaren, resp. nachprüfbaren Tatsachen oder Ereignissen gezogen oder begründet werden kann. Dies betrifft sowohl die Art und Weise wie ein Dokument erstellt wurde, als auch wie mit ihm verfahren und vor allem wie es erhalten (aufbewahrt) wurde 5. Nach Abschnitt 7.2 des BS ISO Standard Information and documentation Records management standard6 ist ein Dokument authentisch, wenn es das Dokument ist, das es vorgibt zu sein, es von derjenigen Person erstellt oder versendet worden ist, die vorgibt, das Dokument erstellt oder versendet zu haben, es tatsächlich zu der angegebenen Zeit erstellt oder versendet wurde. 7 Die Annahme der Authentizität elektronischer Dokumente stützt sich dabei wesentlich auf folgende Aspekte:8 auf die Zuverlässigkeit, d. h. begründete und nachvollziehbare Fakten oder Hinweise, dass der Inhalt eines Dokuments als vollständige und korrekte Wiedergabe derjenigen Tatsachen oder Ereignisse angesehen werden kann, von denen es vorgibt, Zeugnis abzulegen oder zu berichten, die Verkehrsfähigkeit (oder auch Brauchbarkeit ) elektronischer Dokumente, d.h. die Tatsache, dass die als authentisch apostrophierten Dokumente jederzeit lokalisiert und wieder vorgelegt, d. h. auf den zum Zeitpunkt der Wiedervorlage gängigen IT-Systemen präsentiert und interpretiert (gelesen) werden können, die Integrität elektronischer Dokumente, d.h. die Unverändertheit elektronischer Dokumente sowie die eindeutige und nachweisliche, d. h. nicht abstreitbare, Zuordnung der Urheberschaft eines elektronischen Dokuments zu einer Person oder sonstigen Quelle. Die Integrität elektronischer Dokumente bezieht sich nach BS ISO auf die Vollständigkeit und Konsistenz des Dokuments: Einem Dokument wird hiernach Integrität zugebilligt, wenn es über den gesamten Zeitraum seiner Lebensdauer hinweg in allen seinen wesentlichen, d. h. vornehmlich zweckbestimmten Merkmalen, nachweislich vollständig und unverfälscht ist. 9 3 Siehe hierzu bspw. Fischer-Dieskau, S.: Das elektronisch signierte Dokument als Mittel zur Beweissicherung, Band 12 der Rei he Der elektronische Rechtsverkehr, 1. Auflage, Nomos-Verlag, 2005, und Albrecht, A. (2010): Authentizität im elektronischen Rechtsverkehr und Persönlichkeitsschutz beim Einsatz biometrischer Verfahren, S. 129 ff., unter: In der Informatik wird beispielsweise eine Nachricht dann als authentisch bezeichnet, wenn sie sicher einem Sender zugeordnet werden kann. Vgl. Generische Anforderungen zur langzeitlichen Erhaltung elektronischer Informationen, , S. 8 Fn. 5, ebenda, S. 8 Fn. 5, Ebenda, S. 7 Siehe hierzu auch Higgins, S.: Standards Watch Papers ISO15498, unter: Generische Anforderungen zur langzeitlichen Erhaltung elektronischer Informationen, Fn. 5, ebenda S. 9 17

18 Teil 1: Sicherheitsanforderungen Kryptografische Signaturen Der tatsächliche Nachweis der Integrität eines elektronischen Dokuments lässt sich von speziellen Hard waretechniken wie nur einmal beschreibbare Speichermedien abgesehen am ehesten durch kryptografische Maßnahmen führen. Dabei wird von einem Dokument ein digitaler Fingerabdruck erzeugt, der geeignet ist, nachträgliche Manipulationen sicher zu erkennen. Solche Fingerabdrücke werden mit kryptografisch sicheren Hashfunktionen berechnet und zusammen mit dem Dokument versandt bzw. gespeichert, so dass der Empfänger oder Objektnutzer anhand dieses Fingerabdrucks die Integrität des Objekts prüfen kann. Eine Hashfunktion ist eine mathematisch oder anderweitig definierte Funktion, die ein Eingabedatum va riabler Länge aus einem Urbildbereich auf ein (in der Regel kürzeres) Ausgabedatum fester Länge, den Has hwert (engl. auch message digest) in einen Bildbereich abbildet. Das Ziel einer solchen Operation ist, einen Fingerabdruck der Eingabe zu erzeugen, anhand dessen überprüft werden kann, ob eine bestimmte Eingabe mit dem Original übereinstimmt. Kern kryptografischer Hashfunktionen sind Folgen gleichartiger Kompressionsfunktionen, durch die eine Eingabe blockweise zu einem Hashwert verarbeitet wird. Zu den wichtigsten Eigenschaften kryptografischer Hashfunktionen gehören: (1) die so genannte Einwegfunktionalität, d. h. es soll nur mit unvertretbar hohem Aufwand möglich sein, eine Umkehrfunktion zu finden und aus einem gegebenen Hashwert das Original zu berechnen. (2) die so genannte Urbildresistenz (auch als schwache Kollisionsresistenz bezeichnet), d. h. es soll praktisch unmöglich sein, zu einem gegebenen Hashwert ein zweites Original zu finden, das zu dem gegebenen Has hwert passt. (3) die so genannte starke Kollisionsresistenz, d. h. es soll praktisch unmöglich sein, auf systematischem Wege zwei Originale zu finden, die den gleichen Hashwert ergeben. 10 Um die Urheberschaft eines elektronischen Dokuments zweifelsfrei feststellen zu können, benötigt man dagegen zwei Dinge: 1. eine vertrauenswürdige und vor allem nachprüfbare digitale Identität des Urhebers, respektive der Quelle des Dokuments sowie 2. eine unauflösbare, fälschungssichere und nachweisliche Verknüpfung dieser digitalen Identität mit dem Dokument. Fasst man Identität als die Summe derjenigen Merkmale, anhand derer ein Individuum oder ein Objekt von anderen unterschieden werden kann, so kommen für die Herstellung einer digitalen Identität natürlich nur diejenigen Merkmale infrage, die digital erfasst werden können (auch mit Hilfe biometrischer Verfahren). Welche Merkmale infrage kommen, wird nach Mezler-Aldenberg 11 vornehmlich durch folgende Faktoren bestimmt: Die technischen Möglichkeiten, ob es wirtschaftlich sinnvoll ist, das individuelle Sicherheitsbedürfnis der Organisationen und die gesetzlichen Rahmenbedingungen. Die gesetzlichen Rahmenbedingungen wirken dabei vor allem in zwei Richtungen 1. Welche Daten schützenswert sind und wie mit ihnen umzugehen ist. 2. Welche Daten zu welchen Anlässen notwendig sind. 10 Schneier, B.: Angewandte Kryptografie, Addison-Wesley, München 1996, S, 491 ff., und Eckert, C.: IT-Sicherheit, Oldenburg Verlag München, 2008, S. 345ff. 11 Mezler-Aldenberg, C.: Identity Management, dpunkt Verlag, Heidelberg, 2008, S. 7ff. 18

19 Sicherheitsanforderungen Teil 1: Die heute gebräuchlichste Form elektronischer Identitäten sind elektronische Zertifikate. Diese binden digitale Identitätsmerkmale (Name, Anschrift, usw.) einer Person P an ein weiteres für die elektronisch eindeutige Authentisierung benutztes digitales Attribut ap. Die Verknüpfung wird durch einen vertrauenswürdigen Dritten, den Aussteller des Zertifikats, in einer elektronischen, d.h. maschinenlesbaren Datei bescheinigt. Bezeichnet auth(p,ap) die Authentizität der Bindung eines digitalen Attributs ap an die Person P, dann bezeichnet cert(, a, P, ap) ein Zertifikat, das die Bindung von Attribut ap an P durch einen vertrauenswürdigen Dritten bescheinigt. Das Zertifikat ist vorgeblich12 ausgestellt vom Teilnehmer und kryptografisch versiegelt mit einer Operation, die sich mit dem Attribut a und der Kenntnis des Algorithmus der Operation nachvollziehen lässt. Um nun eine zweifelsfreie, d.h. nicht abstreitbare Bindung zwischen der Person P einem Dokument D herzustellen, ist es erforderlich, das der Person P zugewiesene und bescheinigte Attribut a P so mit D zu verknüpfen, dass diese Verknüpfung jederzeit nachvollzogen werden kann. Die dafür gebräuchliche kryptografische Operation wird als elektronische (digitale) Signatur bezeichnet. 13 Die digitale Signatur - als elektronische Variante der eigenhändigen Unterschrift basiert auf dem Einsatz asymmetrischer Kryptoalgorithmen, bei denen ein Schlüsselpaar, bestehend aus einem privaten Schlüssel (private key, Kpriv) und einem öffentlichen Schlüssel (public key, Kpub), verwendet wird. Hierbei ist der private Schlüssel K priv, der zur Erzeugung einer Signatur S = Sign (m, K priv) verwendet wird, nur für den Signaturschlüsselinhaber zugänglich. Der öffentliche Schlüssel K pub, der zur Prüfung von Signaturen mit der Funktion V= Verifiy (m, S, K pub) verwendet wird, steht hingegen jedermann zur Verfügung. Die Schlüssel stehen insofern in einer Beziehung, als man mit ihrer Hilfe die zueinander inversen Operationen des Erstellens und Prüfens von Signaturen ausführen kann. Die Sicherheit der Methode beruht darauf, dass es praktisch unmöglich ist, den privaten Schlüssel aus dem öffentlichen Schlüssel herzuleiten, selbst unter Zuhilfenahme leistungsfähigster Rechnersysteme und Jahren an Rechenzeit. Daher kann der öffentliche Schlüssel in einem öffentlich zugänglichen Verzeichnis hinterlegt werden, ohne damit den privaten Schlüssel preiszugeben Vor der Prüfung der kryptografischen Operation, mit dem Attribut a, ist nicht sicher gestellt, dass das Zertifikat tatsächlich von ausgestellt wurde 13 Teilweise werden diese beiden Begriffe synonym verwendet. Der Begriff der digitalen Signatur hat sich mittlerweile aber weitgehend für Verfahren eingebürgert, die auf so genannter Public-Key-Kryptografie basieren und Authentizität sowie Datenintegrität gewährleisten. Er ist also technisch definiert. In Rechtstexten hingegen wird mehrheitlich der Begriff der elektronischen Signatur verwendet und weiter gefasst als der Begriff der digitalen Signatur (so ist etwa weder der Einsatz von Public-Key-Kryptografie noch die Sicherung der Datenintegrität Voraussetzung der «einfachen elektronischen Signatur» im Sinne von 2 Abs. 1 SigG. Genau gesehen ist dieser Unterschied indessen kaum von Bedeutung, denn zumindest dort, wo in so genannten offenen Benutzergruppen kommuniziert werden soll (also dort, wo auch die Erstkontakte auf elektronischem Weg stattfinden und damit kein Austausch geheimer Schlüssel und auch keine vertragliche Regelung der Kommunikation möglich ist), gibt es zur Public-Key-Kryptografie keine Alternativen, und allein diese offenen Benutzergruppen werden jeweils durch gesetzliche Signaturregulierungen abgedeckt. Aus diesem Grund sieht auch der neue Personalausweis neben der eid-funktion für die Authentifizierung ein eigenes Zertifikat für die Signatur vor. (Schlauri, S.: Elektronische Signaturen, Diss. Univ. Zürich 2002, unter: ) 14 Korte. U., Hühnlein, D.: Grundlagen der elektronischen Signatur,, SecuMedia Verlag Bonn, 2006, S

20 Teil 1: Sicherheitsanforderungen Das Zertifikat cert (, Kpub, P, KpubP) bescheinigt in diesem Fall die Bindung der Identität der Person P an den öffentlichen Schlüssel KpubP von P und ist digital signiert mit dem privaten Schlüssel Kpriv des vertrauenswürdigen Dritten, zu dem der öffentliche Schlüssel Kpub des Dritten passt. Die Verknüpfung des Dokumentes D mit dem aus dem Schlüsselpaar (KprivP, KpubP) bestehenden und durch das Zertifikat bescheinigten Identitätsmerkmals der Person P geschieht nun bspw. durch Verschlüsselung des digitalen Fingerabdrucks von D als eindeutigem, digitalen Repräsentanten des Dokuments mit dem privaten Schlüssel KprivP. Die zweifelsfreie Verknüpfung eines elektronisch signierten Dokumentes mit dem Schlüsselinhaber P und damit die tatsächlich nachvollziehbare Authentizität elektronisch signierter Dokumente hängt auch von den eingesetzten technischen Authentifizierungsverfahren ab, mit denen der Signiervorgang in Gang gesetzt wird. Gemäß 17 (1) SigG ist daher bei der qualifizierten Signatur der Einsatz sicherer Signaturerstellungseinheiten vorgeschrieben, die den Signaturschlüssel gegen unberechtigte Nutzung des Signaturschlüssels schützen sollen. Der Schutz gegen die unberechtigte Nutzung des Signaturschlüssels wird in der Regel (d. h. marktübliche Signaturerstellungseinheiten) durch Wissens- und Besitzelemente (d. h. die Eingabe einer PIN und der Besitz einer Smartcard) hergestellt Beweiswerterhalt kryptografisch signierter Unterlagen (TR-ESOR) Das Ziel einer auch auf lange Zeiträume angelegten Beweiswerterhaltung kryptografisch signierter Unterlagen ist, die für die Dauer der Aufbewahrung mögliche Nachweisführung, dass bestimmte digitale Dokumente und Daten (Inhaltsdaten) sowie zugehörige Metainformationen zu einem nachweisbaren Zeitpunkt vorgelegen haben und seitdem nicht verändert wurden (Integrität). Soweit erforderlich, sind zusätzlich nachprüfbare Nachweise über den Aussteller (Authentizität) der aufbewahrten Dokumente und Daten entsprechend den rechtlichen Anforderungen vorzuhalten. Aufgabe eines Gesamtsystems zur Speicherung und zum Beweiswerterhalt (kryptografisch signierter) Unterlagen auch für lange Zeiträume ist es daher, für die digitalen Inhalte und Beweis-relevante Zusatzdaten die Verfügbarkeit und Lesbarkeit, die Integrität (Unversehrtheit), die Authentizität (daraus folgt auch die Nichtabstreitbarkeit) und Datenschutz, Datensicherheit und Vertraulichkeit für die Dauer der vorgesehenen oder auch aus rechtlichen oder anderen Erfordernissen heraus vorgeschriebenen Aufbewahrungsfristen zu gewährleisten. Die zur Archivierung eingesetzten IT-Anwendungen (IT-Services) sollten daher gemäß der Technischen Richtlinie des BSI TR Beweiswerterhaltung kryptografisch signierter Dokumente folgende Anforderungen erfüllen: die Erzeugung der zu archivierenden Daten in definierten langfristig verkehrsfähigen und standardisierten Datenformaten (z. B. PDF oder ML), falls aus fachlicher Sicht, d. h. durch Rechtsvorschriften oder sonstige Regelungen, geboten, muss die Anwendung imstande sein, die zu archivierenden Nutzdaten vor der Ablage im Archivsystem mit einer elektronischen Signatur in einer durch die Rechtsvorschriften oder sonstigen Regelungen geforderten 20

21 Sicherheitsanforderungen Teil 1: Qualität zu versehen15. Um die Gültigkeit von Signaturen über die Dauer der vorgesehenen oder vorgeschriebenen Aufbewahrungsfristen nachweisen zu können, wird empfohlen, mit der Ausführung der Signatur zugleich sämtliche für den Gültigkeitsnachweis der Signatur erforderlichen Verifikationsdaten zu beschaffen und gemeinsam mit den Signaturdaten innerhalb des Datenspeichers abzulegen. Der Umfang der erforderlichen Verifikationsdaten bestimmt sich vornehmlich aus dem Ziel der erforderlichen Nachweissicherung16. Der IT-Service muss gewährleisten können, dass die Signatur- und Verifikationsdaten für die Dauer der Aufbewahrung sicher und unzweifelhaft mit den signierten Nutzdaten verknüpft sind. Weiterhin muss die Anwendung für die Archivierung signierter Dokumente eine Funktion zum Prüfen von Signaturen anbieten. Auch von solchen Signaturen, die nicht durch die Anwendung selbst erstellt wurde17. Die IT-Anwendungen müssen über sichere Zugriffsschutzmechanismen auf der Grundlage eines zuverlässigen und konfigurierbaren Berechtigungssystems verfügen. Die Anwendung oder die Anwendungsumgebung muss daher auch über ein eigenes zuverlässiges und sicheres Identifikationsund Authentisierungssystem verfügen. Es ist organisatorisch sicherzustellen, das nur die autorisierten Benutzer auch tatsächlich die notwendigen Berechtigungen innerhalb der Anwendung erhalten bzw. besitzen. Die IT-Anwendungen sollen für jedes Archivdatenobjekt einen eindeutigen Bezeichner (eine Archivdatenobjekt ID) erzeugen und an den Nutzer zurückgeben. Diese Archivdatenobjekt ID sollte für jeden Zugriff auf das Archivsystem vorgelegt werden müssen. Die IT-Anwendungen müssen Schnittstellenfunktionalitäten zum Abruf und Löschen bereits archivierter Dokumente und Daten sowie zum Abruf der technischen Beweisdaten zum Nachweis der Authentizität und Integrität von archivierten Informationen besitzen. Archivoperationen, insbesondere aber Löschvorgänge, sollten zwingend protokolliert, die Protokolle vor Verlust und Manipulation geschützt werden. Die IT-Anwendungen müssen zum Erhalt des Beweiswertes signierter Unterlagen imstande sein, elektronische Signaturen gemäß 17 SigV zu erneuern. 1.3 Schutzbedarf für SaaS-Archivsysteme Der Schutzbedarf archivierter Unterlagen bemisst sich vor allem an den möglichen Schäden, die mit einer unbefugten Kenntnisnahme, einer Manipulation, einem Verlust oder einer Nichtverfügbarkeit archivierter Daten verbunden sind. Im Folgenden wird der Schutzbedarf bezüglich Vertraulichkeit, Verfügbarkeit und Integrität unterschieden und in drei Stufen (normal, hoch, sehr hoch) in Anlehnung an den IT-Grundschutz (BSI Standard 100-2) unterteilt. Dies ist in Tabelle 2 veranschaulicht. 15 Für die Erstellung elektronischer Signaturen und Zeitstempel sind ausschließlich von der Bundesnetzagentur veröffentlichte und als sicherheitstechnisch unbedenklich eingestufte Schlüssellängen und Algorithmen zu verwenden. 16 Hintergrund dieser Forderung ist, dass zwischen dem Zeitpunkt der Signaturerstellung und der eigentlichen Archivierung eine beträchtliche Zeitspanne liegen kann. Das Archivsystem prüft zwar laut Empfehlung die enthaltenen Signaturen bei Archiveingang, kann die Gültigkeit der dafür genutzten Zertifikate zum Signaturerstellungszeitpunkt jedoch nur dann prüfen, wenn die Zertifizierungsdiensteanbieter entsprechende Informationen noch vorhalten. Ist dies nicht (mehr) der Fall, kann die enthaltene Signatur nicht geprüft werden und die Beweiskraft der Daten ist quasi verloren. 17 Die Gültigkeitsprüfung der Signaturen muss in jedem Falle umfassend, vollständig und so ausgestaltet sein, dass aus dem Prüfergebnis die Erfüllung der in der europäischen Richtlinie für elektronische Signaturen wie auch im Singnaturgesetz festgelegten Anforderungen an fortgeschrittene und qualifizierte elektronische Signaturen festgestellt werden kann. Sie muss sich darüber hinaus auf die gesamten Zertifikatsketten (Signaturzertifikate des Ausstellers, der Zertifizierungsstelle und der Wurzelzertifizierungsinstanz) sowie alle Verifikationsdaten und Zeitstempel beziehen und nachweislich erkennbar machen, dass die einer elektronischen Signatur zugrunde liegenden bzw. beigefügten Zertifikate zum Signaturzeitpunkt gültig und nicht gesperrt und die eingesetzten kryptografischen Algorithmen und Parameter zum Signaturzeitpunkt sicherheitsgeeignet waren 21

22 Teil 1: Sicherheitsanforderungen Generell muss dabei, wie im gesamten Sicherheitsprofil, auf den Blickwinkel der Schutzbedarfsfeststellung geachtet werden. Hier, wie im gesamten Sicherheitsprofil, erfolgt die Sicherheitsanalyse (inklusive der Maßnahmenauswahl) maßgeblich aus dem Blickwinkel des Cloud-Anbieters und NICHT aus der Sicht des Cloud-Abonnenten. Der Abonnent sollte immer entscheiden, ob er einen Cloud-Dienst nutzt und wie zuvor bei jedem Outsourcing-Vorhaben sollte diese Entscheidung gut durchdacht sein. Wenn eine Institution überlegt, für die Archivierung ihrer Daten eine Cloud-Dienstleistung zu verwenden, andererseits aber den Schutzbedarf der Daten als sehr hoch einstuft, also eine Offenlegung (Vertraulichkeit), eine ungewollte Veränderung (Integrität) oder Nichtverfügbarkeit über einen Zeitraum von mehr als 53 Minuten 18 über ein Jahr (im 24x7x365Modus) kumuliert fundamentale gesetzliche Verstöße, Gefahr für Leib und Leben und ruinöse, exis tenzbedrohende Folgen haben kann, dann sollte für die Archivierung die Entscheidung lauten, nicht in die Cloud zu gehen. 19 Der Schutzbedarf aus der Perspektive des Cloud-Anbieters wird in den nachfolgenden Kapiteln näher erläutert. Dabei wird in der Regel von einem Schutzbedarf bis hoch ausgegangen. Je kleiner der Cloud-Anbieter desto größer ist der Schaden, der durch Kundenverlust entsteht, sodass gerade kleinere Cloud-Anbieter ihren Schutzbedarf mit sehr hoch angeben könnten. Da dieses Sicherheitsprofil aber für den gesamten Markt von SaaS-Archivsystem Anbietern gedacht ist, wurde mit der Wahl des Schutzbedarfs versucht, einen möglichst großen Teil des Marktes zu adressieren. Tabelle 2: Schutzbedarfskategorien für ein SaaS Archiv Modell Schutz Vertraulichkeit Integrität Verfügbarkeit bedarf normal Verstöße gegen Vorschriften Geringfügige und Gesetze mit Vertragsverletzungen mit geringfügigen Konsequenzen maximal geringen bzw. geringfügige Konventionalstrafen Vertragsverletzungen mit Es handelt sich um maximal geringen personenbezogene Daten, Konventionalstrafen durch deren Verarbeitung Es handelt sich um der betroffene CSA in personenbezogene Daten, seiner gesellschaftlichen durch deren Verarbeitung der Stellung oder in seinen betroffene Cloud Service wirtschaftlichen Abonnent (CSA) in seiner Verhältnissen gesellschaftlichen Stellung beeinträchtigt werden oder in seinen kann. wirtschaftlichen Eine Beeinträchtigung der Verhältnissen beeinträchtigt persönlichen werden kann. Unversehrtheit erscheint Eine Beeinträchtigung der nicht möglich. persönlichen Unversehrtheit Die Beeinträchtigung scheint nicht möglich. würde von den Geringfügige Vertragsverletzungen mit maximal geringen Konventionalstrafen Die Beeinträchtigung würde von den betroffenen CSA als tolerabel eingeschätzt werden. Die maximal tolerierbare Ausfallzeit ist größer als 24 Stunden. Eine geringe Ansehensoder Vertrauensbeeinträchtig ung ist für den CSP zu erwarten. Der finanzielle Schaden bleibt für den CSP 18 Wie diese Zeitangabe zustande kommt, wird in Kapitel erläutert. 19 Eine mögliche Sicherheitsmaßnahme gegen eine unbefugte Kenntnisnahme und Manipulation gespeicherter Daten ist natürlich die ausschließliche Speicherung verschlüsselter Daten. Voraussetzung hierfür ist allerdings der Einsatz ausreichend sicherer kryptografischer Verfahren und Techniken durch den Serviceabonnenten auf der Grundlage eines zuverlässigen Kryptokonzeptes gemäß IT-Grundschutz. 22

23 Sicherheitsanforderungen Teil 1: Schutz Vertraulichkeit Integrität Verfügbarkeit bedarf Eine geringe Ansehens- oder Vertrauensbeeinträchtigung des CSP ist zu erwarten. betroffenen CSA als tolerabel eingeschätzt werden. Der finanzielle Schaden bleibt für den Cloud Service Provider (CSP) tolerabel. Eine geringe Ansehensoder Vertrauensbeeinträchtigung des CSP ist zu erwarten. tolerabel. Der finanzielle Schaden bleibt für den CSP tolerabel. Hoch Verstöße gegen Vorschriften Vertragsverletzungen mit und Gesetze mit erheblichen hohen Konsequenzen Konventionalstrafen sehr hoch Vertragsverletzungen mit hohen Konventionalstrafen. Die Beeinträchtigung würde Vertragsverletzungen mit Es handelt sich um von einzelnen hohen Konventionalstrafen personenbezogene Daten, betroffenen CSA als bei deren Verarbeitung der nicht tolerabel Es handelt sich um betroffene CSA in seiner eingeschätzt. personenbezogene Daten, bei gesellschaftlichen Stellung deren Verarbeitung der Eine breite Ansehensoder in seinen betroffene CSA in seiner wirtschaftlichen oder gesellschaftlichen Stellung Verhältnissen erheblich Vertrauensbeeinträchtig oder in seinen beeinträchtigt werden ung für den CSP ist zu wirtschaftlichen kann. erwarten. Verhältnissen erheblich Der Schaden bewirkt beeinträchtigt werden kann. Die Beeinträchtigung würde von einzelnen beachtliche finanzielle Eine Beeinträchtigung der Betroffenen als nicht Verluste für den CSP, ist persönlichen Unversehrtheit tolerabel eingeschätzt. jedoch nicht kann nicht absolut existenzbedrohend. Eine breite Ansehensausgeschlossen werden. oder Eine breite Ansehens- oder Vertrauensbeeinträchtigu Vertrauensbeeinträchtigung ng für den CSP ist zu für den CSP ist zu erwarten. erwarten. Der Schaden bewirkt Der Schaden bewirkt beachtliche finanzielle beachtliche finanzielle Verluste, ist jedoch nicht Verluste für den CSP, ist existenzbedrohend. jedoch nicht existenzbedrohend. Fundamentaler Verstoß gegen Vorschriften und Gesetze Vertragsverletzungen, deren Haftungsschäden ruinös sind. Vertragsverletzungen, deren Haftungsschäden ruinös sind. Es handelt sich um Die Beeinträchtigung personenbezogene Daten, würde von allen bei deren Verarbeitung Betroffenen als nicht eine Gefahr für Leib und tolerabel eingeschätzt Vertragsverletzungen, deren Haftungsschäden ruinös sind. 23

24 Teil 1: Sicherheitsanforderungen Schutz Vertraulichkeit Integrität Verfügbarkeit bedarf Es handelt sich um Leben oder die werden. Die maximal persönliche Freiheit der tolerierbare Ausfallzeit personenbezogene Daten, bei betroffenen Kunden des ist kleiner als eine deren Verarbeitung eine CSA gegeben ist. Stunde. Gefahr für Leib und Leben oder die persönliche Freiheit Gravierende Eine landesweite der betroffenen Kunden des Beeinträchtigungen der Ansehens- oder CSA gegeben ist. persönlichen Vertrauens Gravierende Unversehrtheit sind beeinträchtigung, möglich. eventuell sogar Beeinträchtigungen der existenzgefährdender persönlichen Unversehrtheit Gefahr für Leib und Leben Art, ist denkbar. sind möglich. Gefahr für Leib Die Beeinträchtigung und Leben Der finanzielle Schaden würde von allen ist für den CSP Betroffenen als nicht existenzbedrohend. tolerabel eingeschätzt werden. Eine landesweite Ansehens- oder Vertrauensbeeinträchtigung für den CSP, eventuell sogar existenzgefährdender Art, ist denkbar. Der finanzielle Schaden ist für die Institution existenzbedrohend Vertraulichkeit Datenschutz Für das Schutzziel Vertraulichkeit muss der Schutz von Informationen vor der Kenntnisnahme durch unbefugte Personen gewährleistet werden. Ein Archivsystem speichert in der Regel Unternehmensdaten aus Marketing, Vertrieb, Kundendienst, Produktion, Forschung und Entwicklung, Rechnungs- und steuerrecht lich-relevante Daten sowie Personaldaten. Eine unbefugte Kenntnisnahme, eine Manipulation oder ein Verlust der Daten kann für den Serviceabonnenten wie den Serviceanbieter erhebliche Ansehensverluste und in der Folge auch wirtschaftliche Konsequenzen haben, beispielsweise durch die Androhung strafrechtlicher oder zivilrechtlicher Zwangsmaßnahmen. Dies gilt zunächst ungeachtet auch der notwendigen datenschutzrechtlichen Unterscheidung zwischen Angaben zu natürlichen Personen bzw. Angaben über Firmen kunden. Soweit es sich um personenbezogene Daten handelt, d. h. um Einzelangaben über persönliche und sachli che Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person, sind diese in Deutschland grundsätzlich durch das BDSG geschützt. Nach 28 Abs. 1, Satz 1, Nr. 1 ist das Erheben, Speichern, Verän dern oder Übermitteln personenbezogener Daten oder ihre Nutzung für die Erfüllung eigener Geschäfts zwecke (nur) zulässig, wenn es der Zweckbestimmung eines Vertragsverhältnisses oder vertragsähnlichen Vertrauensverhältnisses mit dem Betroffenen dient 20. Ein über diese Zweckbestimmung hinausgehendes 20 Hat die datenerhebende Stelle ihren Sitz in einem Drittland, findet das BDSG immer auch auf Datenerhebungen und Datenverarbeitungen in Deutschland Anwendung, auch wenn die Stelle ausschließlich von ihrem Heimatland agiert. Proble matisch wird es, wenn die Datenerhebung, Verarbeitung und Speicherung auf weltweit zugänglichen und nicht in 24

25 Sicherheitsanforderungen Teil 1: berechtigtes Interesse an der Speicherung und Nutzung von Daten kann nach 28 Abs. 1 Satz 1 Nr. 2 vorliegen, wenn dies der Werbung neuer Kunden oder aber der Marktbeobachtung dient, oder wenn im Unter nehmen bereits existierende Kundendaten ausgewertet werden sollen, um auf dieser Grundlage die Kun denbeziehungen durch weitere Angebote zu vertiefen 21. In jedem Fall sind nach 28 Abs. 1 Satz 2 die Zwecke für die Daten verarbeitet oder genutzt werden sollen, konkret festzulegen. Schutzwürdige Interessen des Betroffenen dürfen dem selbstverständlich nicht entgegenstehen. Schutzwürdige Interessen sind beispielsweise immer dann zu unterstellen, wenn sensible Daten aus unterschiedlichen Vertragszusammenhängen ohne Kenntnis und Zustimmung des Betroffenen zusammengeführt und genutzt werden sollen, beispielsweise mit der Erstellung von Kundenprofilen aus unterschiedlichen Datenquellen. Für die Einbeziehung eines Dritten in die Speicherung und Nutzung sowie Verarbeitung personenbezogener Daten sind nach deutschem Datenschutzrecht grundsätzlich zwei Ausgestaltungen möglich: die Datenübermittlung und die Auftragsdatenverarbeitung (ADV). Bei der Datenübermittlung wird der Cloud-Dienstleister als eigenverantwortlicher Dritter und weisungsunabhängiger Dienstleister tätig. Dies dürfte für SaaS Archivsystem ausgeschlossen sein. Aus rein technischer Perspektive ist Cloud Computing Auftragsdatenverarbeitung (ADV). Datenschutzrechtliche Grundlage hierfür ist ein nach Maßgabe des 11 BDSG geschlossener Vertrag über die ADV. Eine Interessenabwägung ist dann nicht erforderlich, was zur Folge hat, dass gemäß 3 Abs. 8 BDSG der Auftragsda tenverarbeiter nicht als Dritter i. S. d. BDSG gilt und damit eine Übertragung an diesen datenschutzrecht lich keine Übermittlung darstellt (Privilegierungswirkung 22). Grundlegende Voraussetzung für eine ADV ist, dass der Auftragsdatenverarbeiter in Bezug auf den Umgang mit personenbezogenen Daten strikt weisungs gebunden und ohne eigenen Entscheidungsspielraum verfährt 23. Die Kehrseite der datenschutzrechtlichen Privilegierung der ADV ist daher, dass die Verantwortlichkeit des Servicenutzers für die Einhaltung des Datenschutzrechtes auch in Bezug auf die Tätigkeit des Cloud-Dienstleisters (gem. 11 Abs. 1 BDSG) erhalten bleibt. Gemäß Art. 2 c) der EU-DSRL ist verantwortlich, wer über die Zwecke und Mittel der Verarbeitung entscheidet. Die Auslagerung von Daten, ihrer Verarbeitung und Speicherung hat also nicht auch eine Auslagerung der Verantwortlichkeit zur Folge. Nach 11 Abs. S. 2 Nr. 6 BDSG ist deshalb in dem Vertrag über die ADV ebenfalls zwingend zu regeln, ob der Cloud-Dienstleister Subunternehmer einsetzen darf. Denn, der Nutzer der Cloud-Dienstleistung haftet gegenüber einem Geschädig ten auch für Fehler durch Subunternehmer. Nach 11 Abs. 2 S. 2 Nr. 1 und Nr. 10 BDSG sind darüber hinaus sowohl die Laufzeit des Vertrages als auch die Löschung von Daten beim Auftragsdatenverarbeiter zum Vertragsende vertraglich zu regeln. Aus technischer Sicht sind territoriale Grenzen im Cloud Computing natürlich unerheblich. Für das geltende Recht ist dagegen der Ort der Verarbeitung relevant. Der Bundesbeauftragte für Datenschutz und Infor mationsfreiheit (BfDI) stellt daher zu Recht die Frage, wie eine verantwortliche Stelle ihrer Verantwortung gerecht werden will, wenn Serverkapazitäten ad hoc und ggf. sogar grenzüberschreitend ausgewählt werden.24 Nach Ansicht des Deutschen Anwaltsvereins ist deshalb Cloud Computing auch nicht mit den EUDatenschutzrichtlinien vereinbar, wenn die Verarbeitung auf Servern außerhalb der EU erfolgt. 25 Der Versuch, den Ort der Speicherung oder Verarbeitung auf einfache Weise feststellbar zu machen, wird durch Deutschland betrieben Internetseiten erfolgt. 21 Bizer, J.: Datenschutz im Data Warehouse Die Verwendung von Kunden- und Nutzerdaten zu Zwecken der Marktforschung. In: Horster, P., Fox, D. (Hrsg.) DuD Konzepte, Realisierungen, rechtliche Aspekte, Anwendungen, Braunschweig/Wiesbaden 1999, S , zitiert nach Melchior, A.: CRM und Datenschutz, Akademiker Verlag, Saarbrücken 2012, S Ein in der Praxis wesentlicher Ausschluss der Privilegierungswirkung ergibt sich aus der Beschränkung des freien Daten flusses auf den EU-/EWR-Binnenbereich. Danach ist eine ADV mit einem Cloud-Dienstleister in einem sog. Drittstaat kraft Gesetzes ausgeschlossen ( 3 Abs. 8 S. 3 BDSG). Drittstaaten sind hierbei alle Staaten, welche nicht Mitglied der EU oder des EWR sind. 23 Ein Vertrag über die ADV muss wegen 11 Abs. 5 BDSG selbst dann abgeschlossen werden, wenn der externe Dritte zwar keine Datenverarbeitung vornehmen soll, aber bei seiner Tätigkeit für den Auftraggeber ein Zugriff auf personenbezogene Daten tatsächlich nicht ausgeschlossen werden kann (siehe Eckhardt, J.: Datenschutz im Cloud Computing aus Anbietersicht. In: Borges, G., Schwenk, J. (Hrsg.): Daten- und Identitätsschutz in Cloud Computing, E-Government und E-Commer ce, Springer Verlag Berlin-Heidelberg 2012, S Siehe unter 25

26 Teil 1: Sicherheitsanforderungen technische Datenübertragungsprotokolle indes nicht unterstützt. Eine Reihe von Cloud Dienstleistern bieten daher sog. Regionalgarantien an, d. h., dass Daten, die in einem europäischen Bereich der Cloud gespeichert oder verarbeitet werden, diesen nicht verlassen 26. Dies wird freilich unterlaufen, wenn beispielsweise Administratoren aus einem nicht-europäischen Wirtschaftsraum auf europäische Daten zugreifen können. Allein vor diesem Hintergrund muss der Schutz von Unternehmensdaten bei der Speicherung durch den Cloud Service Provider im Sinne der oben genannten Klassifizierung hinsichtlich der Vertraulichkeit zumindest als hoch eingestuft werden. Eine unbefugte Kenntnisnahme oder Veränderung durch Dritte muss nach Maßgabe zu erwartender Bedrohungsszenarien ausgeschlossen werden können. In Einzelfällen, insbesondere bei der Speicherung personenbezogener Daten, kann dies auch dazu führen, dass der Schutzbe darf hinsichtlich der Vertraulichkeit mit sehr hoch eingestuft werden muss. Daten juristischer Personen (Firmendaten) unterliegen nicht dem Datenschutzrecht. Dessen ungeachtet kann auch hier eine unzulässige Kenntnisnahme oder Manipulation zu einer erheblichen Beeinträchtigung des Ansehens und der Geschäftstätigkeit des Unternehmens und in der Folge ggf. zu erheblichen finanziellen Verlusten führen, was natürlich auf das Ansehen und das Vertrauen in das Geschäftsgebaren des Service Pro vider nicht ohne Auswirkungen bleiben dürfte. Vorstellbar sind auch erhebliche finanzielle Auswirkungen auf den Provider, sofern Haftungsansprüche an den Serviceabonnenten zivilrechtlich an den Serviceprovider durchgereicht werden. Folglich muss auch für diese Daten ein hoher Schutzbedarf geltend gemacht werden. Das betrifft auch die Zugriffs- und Konfigurationsdaten von (virtuellen und physischen) Kompo nenten und Services, Kommunikationsverbindungen oder Logs eines Archivsystems. Eine unzulässige Kenntnisnahme oder Manipulation kann zu einer Gefährdung führen, die ihrerseits die Ausspähung von Unternehmensdaten ermöglicht oder die Verfügbarkeit archivierter Daten in erheblichem Umfang beeinträchtigt Integrität Wie bereits ausgeführt, speichert ein Archivsystem in der Regel Geschäftsprozess-relevante Unternehmens daten aus Marketing, Vertrieb, Kundendienst, Produktion, Forschung und Entwicklung, Rechnungs- und steuerechtlich-relevante Daten sowie ggf. Personaldaten. Die Manipulation dieser Daten kann dazu führen, dass bestehende Kundenkontakte des Serviceabonnenten abbrechen, Kundenwünsche oder Erwartungen im Vertrieb, im Kundendienst, in der Produktion und Entwicklung nicht oder ungenügend berücksichtigt werden können, Bestellungen oder Lieferungen verspätet ausgeführt oder falsch deklariert werden, Rechnungslegungen oder auch steuerrechtlich-relevante Angaben verfälscht werden. Die Folgen sind ein erheblicher Ansehens- und Vertrauensverlust in die Tätigkeit des Serviceproviders mit ggf. beachtlichen wirtschaftlichen Auswirkungen. Der Schutzbedarf hinsichtlich der Integrität von Archivdaten muss daher ebenfalls als hoch bewertet werden. Ebenso kann die Manipulation von Accountdaten des Servicenehmers bewirken, dass Zugriffe auf das Archiv nicht mehr oder nur mit eingeschränkten Zugriffsrechten möglich sind oder Unbefugten der Zugriff auf Archivdaten möglich wird. Letzteres könnte gleichfalls dazu genutzt werden, Daten des Unternehmens zu manipulieren, auszuspähen oder zu stehlen. In diesem Falle wirkt sich eine Verletzung der Integrität auch auf die Vertraulichkeit aus. Der Schutzbedarf von Accountdaten auf ein Archivsystem muss daher hinsichtlich der Integrität gleichfalls mindestens als hoch eingeschätzt werden Verfügbarkeit Archivierung ist auf die langfristige Speicherung elektronischer Daten ausgelegt. Langfristig bedeutet für 25 Siehe unter zitiert nach Gerber, S., Thiele, P., Zimmer, W.: Cloud Computing in der Öffentlichen Verwaltung? In: Krallmann, H, Zapp, A.: Bausteine einer vernetzten Verwaltung, Erich-Schnidt-Verlag Berlin 2012, S. 232 Fn Hansen, M.: Datenschutz im Cloud Computing In: Borges, G., Schwenk, J. (Hrsg.): Daten- und Identitätsschutz in Cloud Computing, E-Government und E-Commerce, Springer Verlag Berlin-Heidelberg 2012, S

27 Sicherheitsanforderungen Teil 1: dieses Profil bis zu zehn Jahre, was die Zeitdauer einer typischen gesetzlichen Aufbewahrungsfrist entspricht. Vor diesem Hintergrund wird die Schutzbedarfskategorie Verfügbarkeit betreffend in diesem Dokument unterschieden zwischen der Verfügbarkeit im Sinne der Verkehrsfähigkeit (oder auch Brauchbarkeit ) elektronischer Dokumente einerseits und der Verfügbarkeit im Sinne der (technischen) Zuverlässigkeit der Bereitstellung des Archivdienstes andererseits. Verfügbarkeit im Sinne der Verkehrsfähigkeit bezeichnet dabei die Forderung eines auch über lange Zeiträume uneingeschränkten physischen Zugriffs auf die Daten, d. h. dass die gespeicherten Dokumente jederzeit lokalisiert und wieder vorgelegt, d. h. auf den zum Zeitpunkt der Wiedervorlage gängigen IT-Systemen präsentiert und interpretiert (gelesen) werden können. Hinsichtlich der (technischen) Zuverlässigkeit des Archivdienstes können die Verfügbarkeitsklassen (VKs) des Hochverfügbarkeitskompendiums des BSI der Schutzbedarfsfeststellung zugrunde gelegt werden. Dabei wird der Ausfall als kumulierte Nichtverfügbarkeit über ein Jahr bei einer Servicezeit von 24x7x365 angegeben. Nach dieser Klassifikation bedeutet Schutzbedarf normal (VK 1) eine 99%-ige Verfügbarkeit und impliziert, dass der Service kumuliert über ein Jahr höchstens 88 Stunden ausfällt. Hoher Schutzbedarf bei Verfügbarkeit (VK 2 oder 99,9% Verfügbarkeit) bedeutet, dass der Service kumuliert über ein Jahr nicht länger als 9 Stunden ausfällt. Sehr hoher Schutzbedarf (VK 3 oder 99,99% Verfügbarkeit) bedeutet, dass der Service kumuliert über ein Jahr nicht länger 53 Minuten ausfällt. Über den sehr hohen Schutzbedarf hinaus enthält das Hochverfügbarkeitskompendium noch die VK 4 (99,999% Verfügbarkeit), die impliziert, dass der Service über das Jahr kumuliert nicht länger als 6 Minuten ausfällt. Bei noch kürzeren kumulierten Ausfallzeiten (VK 5) spricht man von Disaster-toleranter Verfügbarkeit, bei der jedoch sinnvoll keine Zeit mehr angegeben wer den kann. Da in der Regel in einem Archiv Daten gespeichert werden, die für die Ausführung aktueller operativer Ge schäftsprozesse nur in Ausnahmefällen ständig und ohne zeitliche Verzögerung benötigt werden, sind bei ei nem zeitlich begrenzten Ausfall des Archivsystems nur geringe Ansehens- oder Vertrauensverluste für den Cloud Service Provider zu erwarten. Die Festlegung der Verfügbarkeit im Sinne der Zuverlässigkeit der Be reitstellung des Archivdienstes unterliegt daher weitgehend der Einschätzung des Serviceabonnenten und ist damit Gegenstand vertraglicher Vereinbarungen über die Leistungsgüte eines SaaS Archivsystems. Für dieses Schutzprofil wird für SaaS Archivlösungen der Schutzbedarf bei hinsichtlich der technischen Verfügbarkeit des Service als normal eingestuft. Anders dagegen bei der physischen Verfügbarkeit ( Verkehrsfähigkeit ) gespeicherter Daten. Ein Datenverlust durch den Ausfall oder den unsachgemäßen Umgang mit Speichermedien kann einen erheblichen Vertrau ensverlust, Vertragsverletzungen und in der Folge auch finanzielle Einbußen zur Folge haben. Der Schutzbedarf hinsichtlich der physischen Verfügbarkeit gespeicherter Daten muss daher mit hoch bewertet werden. 1.4 Gefährdungen für die Bereitstellung von SaaS Archivsystemen Obwohl die SaaS-Anwendung aus der Perspektive des Abonnenten sich wie eine monolithische Softwarekomponente verhält, kann in der Regel nicht ausgeschlossen werden, dass sie tatsächlich in einer Multi-Pro vider Architektur implementiert ist, d. h. der SaaS Anbieter selbst sich für die Ausführung der Anwendung externer Ressourcen (beispielsweise Rechenleistung, Speicherkapazitäten oder auch Netzdienstleistern) bedient. Vor diesem Hintergrund müssen für das SaaS Servicemodell zumindest folgende Gefährdungsquellen in Betracht gezogen werden: Gefährdungen, in der Interaktion des Servicedienstleiters mit dem Servicenutzer, Gefährdungen, die aus der Bereitstellung anteilig genutzter physischer Ressourcen durch je verschiedene Serviceabonnenten entstehen, Gefährdungen, die aus der Bereitstellung je verschiedener SaaS Services eines oder mehrerer Dienstleister für die Endnutzer ein und desselben Serviceabonnenten entstehen, und Gefährdungen, die aus der Zusammenarbeit des Servicedienstleisters mit Vertragspartnern (Sub-Dienstleistern) des Dienstleisters entstehen. 27

28 Teil 1: Sicherheitsanforderungen Gefährdungen der Interaktion Zu den Gefährdungen in der Interaktion des Servicenutzers und des Servicedienstleiters gehören: 1. der Ausfall oder die Behinderung des Service ausgelöst durch unerwartete / unvorhergesehene Ereignisse wie straf- oder zivilrechtliche Zwangsmaßnahmen, elementare Gefährdungen wie die Zerstörung (der Verlust) physischer Ressourcen durch Feuer, Wasser oder katastrophalen Ereignissen im Umfeld, der Ausfall oder die Störung von Kommunikations- und Versorgungsnetzen oder sonstiger physischer Infrastrukturen, der Ausfall oder die Störung des Betriebs von Sub-Dienstleistern 2. der Ausfall oder die Behinderung des Service ausgelöst durch organisatorische Mängel wie: fehlende oder ungenügende Regelungen und Dokumentationen zur Aufrechterhaltung des ordnungsgemäßen Betriebs und der damit einhergehenden Zuständigkeiten (separation of duties), fehlendes oder unzureichendes Informationssicherheits-Management, Fehlen von Sicherheitsrichtlinien und eine ungenügende Kontrolle ihrer Umsetzung, die unsichere Administration von Anwendungen ausgelöst durch fehlende oder ungenügende Regelungen und Dokumentationen zur Aufrechterhaltung des ordnungsgemäßen Betriebs und der damit einhergehenden Zuständigkeiten sowie ein fehlendes oder unzureichendes Informations-Sicherheits-Management, eine ungenügende Sicherheitsüberprüfung und ungenügende Schulung der Mitarbeiter in Sicherheitsfragen, fehlendes oder unzureichendes Konfigurations- und Änderungsmanagement, fehlendes oder unzureichendes Management von kryptografischen Material, fehlende oder unzureichende Kontrolle des Zutritts zu schutzbedürftigen Räumen fehlende oder ungenügende Auswertung von Protokolldaten über den ordnungsgemäßen Betrieb und sicherheitsrelevanten Ereignissen, fehlende oder ungenügende Test- und Freigabeverfahren von Hard- und Softwareänderungen (Updates oder Patches) unzureichende vertragliche Regelungen mit Sub-Dienstleistern 3. der Ausfall oder die Behinderung des Service ausgelöst durch menschliches Fehlverhalten wie: die unerlaubte Ausübung (Eskalation) von Rechten, die fahrlässige oder auch unbeabsichtigte Nichteinhaltung von Sicherheitsregelungen und Sicherheitsmaßnahmen, der Verlust der Vertraulichkeit und Integrität von Daten durch fahrlässiges Fehlverhalten oder sorglosem Umgang mit sicherheitsrelevanten Informationen, fehlerhafte Konfiguration und Bedienung von Software- und Hardwarekomponenten, insbesondere Sicherheitskomponenten, Netzwerkgeräten, Servern oder Managementinterfaces zur dynamischen Allokation virtueller und physikalischer Ressourcen, fehlerhafte Interpretation sicherheitsrelevanter Ereignisse, unsachgemäße oder fehlerhafte Nutzung externer Dienstleistungen 28

29 Sicherheitsanforderungen Teil 1: 4. der Ausfall oder die Behinderung des Service ausgelöst durch Fehlfunktion oder Versagen technischer Systeme und Infrastrukturen ausgelöst durch: Ausfall oder Störung interner Versorgungs- und Kommunikationsnetze, fehlende oder fehlerhafte Implementierung von Standards und Standardlösungen, was zu Inkompatibilitäten oder zu neuen Schwachstellen führen kann, fehlende oder unzureichende Standards und Standardlösungen, die zu Inkompatibilitäten oder zu neuen Schwachstellen führen, Einsatz ungeeigneter Technologien, Ausfall oder Störung vorhandener Sicherheitseinrichtungen wie Komponenten zur sicheren Identifikation und Authentisierung von Mandanten und Nutzern, der sicheren Segmentierung und Isolation sowie dynamischen Allokation virtueller und physikalischer Ressourcen, Komponenten zum Schutz der Kommunikation mit externen Entitäten und Datenträgern, oder Komponenten für ein zuverlässiges Sicherheitsmonitoring und Reaktionsverhalten (incident response) auf externe Angriffe, Hard- oder Softwareschwachstellen und -fehler, defekte Datenträger, unerwartete Erschöpfung virtueller und physikalischer Ressourcen, unaufgelöste Konflikte zwischen Nutzeranforderungen und der Cloud Umgebung, Versagen oder Fehlverhalten technischer Leistungen von Sub-Dienstleistern. 5. Ausfall oder Störung des Service durch vorsätzliche Handlungen wie Manipulation von Geräten und Zubehör, Kompromittierung von Daten und Software. Diebstahl oder Fälschung von Identitäten und damit von Zugriffsrechten (Forgery of ID and Access Rights), Missbrauch von Zugriffsrechten, Ausführung von Schadcode und Scans (Untertaking Malicious Code and Scans), Verhinderung von Diensten (DDoS, EdoS), Kompromittierung von Managementwerkzeugen und -schnittstellen Abhören / Manipulation bewegter Daten (Intercepting / Compromise of Data in Transit) Datendiebstahl oder Datenmanipulation gespeicherter Daten (Data Leakage / Compromise) Diebstahl oder Beschädigung von Speichermedien, Kompromittierung kryptografischer Services (beispielsweise durch Verlust oder Kompromittierung des Schlüsselmaterials Kompromittierung oder Manipulation virtueller oder physikalischer Ressourcen (Server, Netze, Speicher, Switches, Router, Firewalls), Verhinderung oder Kompromittierung von Sub-Dienstleistungen (Anwendungen und Services) 29

30 Teil 1: Sicherheitsanforderungen Verbergen von Fehlverhalten durch die Manipulation von Logs und Audits Gefährdungen aus der anteiligen Bereitstellung virtueller und physischer Ressourcen für je verschiedene Serviceabonnenten 1. Der Ausfall oder die Störung des Service ausgelöst durch menschliches Fehlverhalten wie: die fahrlässige oder auch unbeabsichtigte Nichteinhaltung von Sicherheitsregelungen und Sicherheitsmaßnahmen, die fehlerhafte Konfiguration und Bedienung von Software- und Hardwarekomponenten, insbesondere Sicherheitskomponenten, Netzwerkgeräten, Servern oder Managementinterfaces zur dynamischen Allokation virtueller und physikalischer Ressourcen, die fehlerhafte Interpretation sicherheitsrelevanter Ereignisse. 2. Der Ausfall oder die Störung des Service ausgelöst durch technisches Versagen wie: unzureichende bzw. unsichere Segmentierung und Isolation virtueller und physischer Ressourcen, die Erschöpfung, die Störung oder auch der Ausfall anteilig genutzter virtueller und physikalischer Ressourcen. 3. Kompromittierung oder Störung des Service ausgelöst durch vorsätzliche Handlungen die Manipulation von Geräten und Zubehör, die Kompromittierung von Daten und Software, den Diebstahl oder die Fälschung von Identitäten und damit von Zugriffsrechten (Forgery of ID and Access Rights), der Missbrauch von Zugriffsrechten, das Abhören / die Manipulation bewegter Daten (Intercepting / Compromise of Data in Transit), Datendiebstahl oder Datenmanipulation gespeicherter Daten (Data Leakage / Compromise), die Kompromittierung kryptografischer Services (beispielsweise durch Verlust oder Kompromittierung des Schlüsselmaterials, die Kompromittierung oder Manipulation virtueller oder physikalischer Ressourcen (Server, Netze, Speicher, Switches, Router, Firewalls) Gefährdungen aus der Bereitstellung verschiedener Services für Endnutzer eines Serviceabonnenten 1. der Ausfall oder die Störung des Service ausgelöst durch menschliches Fehlverhalten wie: die fahrlässige oder auch unbeabsichtigte Nichteinhaltung von Sicherheitsregelungen und Sicherheitsmaßnahmen, der Verlust der Vertraulichkeit und Integrität von Daten durch fahrlässiges Fehlverhalten oder sorglosem Umgang mit sicherheitsrelevanten Informationen, fehlerhafte Konfiguration und Bedienung von Software- und Hardwarekomponenten, insbesondere Schnittstellen, Sicherheitskomponenten, Netzwerkgeräten, Servern oder Managementinterfaces zur dynamischen Allokation virtueller und physikalischer Ressourcen, fehlerhafte Interpretation sicherheitsrelevanter Ereignisse. 30

31 Sicherheitsanforderungen Teil 1: 2. Kompromittierung oder Störung des Service ausgelöst durch technisches Versagen wie: unzureichende Trennung von Anwendungen (isolation failure), Ausfall von Schnittstellenfunktionalitäten, Erschöpfung anteilig bereitgestellter virtueller und physikalischer Ressourcen, fehlerhafte Zuweisung anteilig bereitgestellter virtueller und physikalischer Ressourcen, unzureichende oder fehlerhafte Abgrenzung von Identitäten und Zugriffsrechten, 3. Kompromittierung oder Störung des Service ausgelöst durch vorsätzliche Handlungen wie: Kompromittierung von Daten und Software, den Diebstahl oder die Fälschung von Identitäten und damit von Zugriffsrechten (Forgery of ID and Access Rights), Missbrauch von Zugriffsrechten (Privilege Escalation), Abhören / Manipulation bewegter Daten (Intercepting / Compromise of Data in Transit), Datendiebstahl oder Datenmanipulation gespeicherter Daten (Protection of Data at Rest / Data Leakage) Diebstahl oder Beschädigung von Speichermedien, Kompromittierung kryptografischer Services (beispielsweise durch Verlust oder Kompromittierung des Schlüsselmaterials, Kompromittierung oder Manipulation virtueller oder physikalischer Ressourcen (Server, Netze, Speicher, Switches, Router, Firewalls) Gefährdungen durch Sub-Dienstleister 1. der Ausfall des Service (Einstellung des Betriebs) ausgelöst durch beispielsweise straf- oder zivilrechtliche Zwangsmaßnahmen, elementare Gefährdungen wie die Zerstörung (der Verlust) physischer Ressourcen durch Feuer, Wasser oder katastrophalen Ereignissen im Umfeld, wirtschaftliche Gründe (Insolvenz), 2. der Ausfall oder die Störung des Service ausgelöst durch organisatorische Mängel: fehlende oder unzureichende Regelungen zwischen Dienstleister und Sub-Dienstleister 3. der Ausfall oder die Störung des Service ausgelöst durch menschliches Fehlverhalten: fahrlässige oder auch unbeabsichtigte Nichteinhaltung von vereinbarten Sicherheitsregelungen und Sicherheitsmaßnahmen, Verlust der Vertraulichkeit und Integrität von Daten durch fahrlässiges Fehlverhalten oder sorglosem Umgang mit sicherheitsrelevanten Informationen durch den Sub-Dienstleister, fehlerhafte Konfiguration und Bedienung von Software- und Hardwarekomponenten, Kommunikationsstrecken und/oder Kommunikationsendpunkten fehlerhafte Interpretation sicherheitsrelevanter Ereignisse. 4. Ausfall oder Störung des Service ausgelöst durch technisches Versagen: 31

32 Teil 1: Sicherheitsanforderungen technisches Versagen oder fehlerhafte Funktion der für die Erbringung der Dienstleistung vereinbarten Ressourcen, Ausfall oder fehlerhaftes Verhalten von Kommunikationsverbindungen. 5. Kompromittierung oder Störung des Service ausgelöst durch vorsätzliche Handlungen Kompromittierung von Daten und Software, Diebstahl oder die Fälschung von Identitäten und damit von Zugriffsrechten (Forgery of ID and Access Rights), Missbrauch von Zugriffsrechten (Privilege Escalation), Abhören / Manipulation bewegter Daten (Intercepting / Compromise of Data in Transit), Datendiebstahl oder Datenmanipulation gespeicherter Daten (Data Leakage / Compromise), Kompromittierung kryptografischer Services (beispielsweise durch Verlust oder Kompromittierung des Schlüsselmaterials, Kompromittierung oder Manipulation virtueller oder physikalischer Ressourcen, Verhinderung von Diensten (DDoS, EDoS). 1.5 Sicherheitsanforderungen In diesem Kapitel sollen Sicherheitsanforderungen aus verschiedenen Standards (ISO und NIST SP rev3), Empfehlungen und Anforderungen von staatlichen Behörden (Eckpunktepapier des BSI Sicherheitsempfehlungen für Cloud Computing Anbieter und NIST FedRAMP) und Empfehlungen sonstiger Konsortien wie die Cloud Control Matrix (CSA CMM) der Cloud Security Alliance (CSA) zusammengestellt werden. Diese Dokumente haben verschiedene Ansprüche. So ist der ISO-Standard mit internationaler Gültigkeit zertifizierbar, der NIST-Standard stellt Anforderungen auf, das Eckpunktepapier gibt Empfehlungen und die CSA CMM gibt Steuerungen an, um das Risikomanagement zu unterstützen. Insofern ist ein echter Vergleich unmöglich. Bei der nachfolgenden Nebeneinanderstellung geht es daher nicht darum, die Qualität, Tiefe oder den Umfang der jeweiligen Dokumente zu beurteilen. Es ist das Ziel aus allen diesen Publika tionen relevante Sicherheitsanforderungen für Customer Relation Management als Software-as-a-Service zu extrahieren und hier übersichtlich zusammenzustellen. Dies soll die Grundlage für die auf der Basis der STRIDE-Analyse zu gewinnenden konkreten Ausgestaltungen dieser Sicherheitsanforderungen sein. Die nachfolgende Definition von Sicherheitsanforderungen im Kontext eines als SaaS bereitgestellten Archivsystems folgt in seiner Struktur dem Eckpunktepapier des BSI Sicherheitsempfehlungen für Cloud Computing Anbieter, konkretisiert jedoch die dortigen Empfehlungen für den Anwendungsfall SaaS Archivierung. In den weiteren Spalten wird auf die den gleichen Inhalt adressierenden Teile der anderen Publikationen (ISO 27001:2005, NIST SP rev3, NIST FedRAMP und CSA CMM) verwiesen und ebenfalls doku mentiert, wenn dieser Aspekt nicht in der jeweiligen Publikation zu finden ist. Dabei ist zu beachten, dass FedRAMP auf NIST SP aufbaut und daher vielfach in der Tabelle eine Fehlanzeige zu sehen ist. Dies ist dem Design von FedRAMP als eine Spezifikation basierend auf NIST SP geschuldet und nicht als eine Schwäche von FedRAMP zu werten. Die Sicherheitsempfehlungen aus dem Eckpunktepapier des BSI sind einerseits im Fließtext enthalten und in unnummerierten Tabellen zusammengefasst. In der nachfolgenden Tabelle ist ein Eintrag in der Spalte BSI der Form 4.1 Tab. (2), (3)" zu lesen als Tabellenzeile 2 und 3 in der Tabelle in Kapitel

33 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsmanagement (Information Security Management - ISM) Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP CSA CMM V1.4 BSI IS-01, IS-02, IS-03 3 Tab: 1, 2 [ISM-01] Der Cloud-Service-Anbieter hat ein anerkanntes (z. A.5.1.1, A.5.1.2, B. nach BSI Standard100-2 zur Vorgehensweise im IT- A.6.1.1, A.6.1.3, Grundschutz oder ISO 27001/2) Informationssicherheits- A Management-System etabliert und implementiert. PL-2, PM-1 [ISM-02] Das Informationssicherheits-Management-System etabliert und setzt eine klare Trennung von Aufgaben (Zuständigkeiten), Rollen und Verantwortlichkeiten durch (separation of duties) und benennt dem Cloud-Service-Abonnenten Ansprechpartner für Sicherheitsfragen. A.6.1.1, A.6.1.2, A.6.1.3, A.6.2.1, A.6.2.2, A.8.1.1, A.8.2.1, A , A AC-5, PM-2 AC-5, AC-6, SA-6 IS-07, IS-08, 3 Tab: IS-09, IS-10, 4 IS-13, IS-15, IS-16, OP-01 [ISM-03] Der Cloud-Service-Anbieter hat ein zuverlässiges Risikomanagement etabliert, das in regelmäßigen Abständen Bedrohungs- und Risikoanalysen für Daten, Anwendungen, virtuelle und physikalische Ressourcen durchführt. Die Ergebnisse werden dokumentiert, vor Verlust und Manipulation geschützt und dem Cloud-Service-Abonnenten auf Anforderung zur Kenntnis gebracht. A.5.1.1, A.5.1.2, A.6.1.1, A.6.2.1, A.6.2.2, A.6.2.3, A , A IR-4, PL-1, PL-6, RA-1, RA-2, RA-3, RA-5, SA-1, SA-3, SA-4, SA-5 RA-1, RA-2, RA-3, RA-5, SA-1, SA-3, SA-4, SA-5, SA-9(1), SA-12 IS-04, IS-05, 3 Tab: RI-01,RI-02, 2 RI-03, RI-04, RI-05, [ISM-04] Sicherheitsrichtlinien, Sicherheitsarchitektur und A.6.1.8, A.8.1.1, CA-2, CA-7, Sicherheitsmaßnahmen des Service werden regelmäßig auf A , A RA-1, RA-2, ihre Umsetzung und Wirksamkeit überprüft. Eine RA-3 Überprüfung kann auf Verlangen des Cloud-Service-Abonnenten auch durch zertifizierte externe Auditoren durchgeführt werden. Die Überprüfung wird dokumentiert. Die Prüfprotokolle und Auditberichte werden vor Verlust und Manipulation geschützt und auf Verlangen dem Cloud-Service-Abonnenten vorgelegt. AU-6, AU-7, CA-1, CA-2, CA-7 CO-01, CO-03, CO-05, DG-08 Sicherheitsarchitektur 33

34 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 Rechenzentrumssicherheit [IFS-01] Der Zutritt zu Betriebsräumen des A.9.1.1, A.9.1.2, Cloud-Service-Anbieters ist nur für sicher und zuverlässig A.9.1.3, A.9.1.4, (Information Facility authentisierten und autorisierten Personen möglich. A Security - IFS) Sicherheit der Anwendung und der Anwendungsumgebung (Application and Environment Security AES) 34 NIST rev3 FedRAMP CSA CMM V1.4 BSI PE-1, PE-2, PE-3, PE-6, PE-7 MP-4, PE-1, PE-2, PE-3, PE-6, PE-7 FS-01, FS-02, 4.1 Tab: FS-03, FS-04, 2, 3 FS-05, FS-06, FS-07,SA-06 [IFS-02] Der Cloud-Service-Anbieter hat eine robuste und redundante Infrastruktur für die Bereitstellung des Services etabliert, die die Verfügbarkeit der Anwendung auch im Falle Störungen, Ausfall einzelner Komponenten und beherrschbarer Elementarschäden sicherstellt. A.9.1.4, A.9.2.1, A.9.2.2, A , A , A.9.2.3, A , A , CP-6, CP-7, CP-8, CP-9, CP-10, PE-9, PE-11, PE-10, PE-12, PE-13, PE-15 CP-6, CP-7, RS-05, RS-06, 4.1 Tab: CP-8, CP-9, RS-07 1, 3, 4, 5 CP-10, PE-9, PE-10, PE-11, PE-12, PE-13, PE-15 [AES-01] Die Anwendung wird in einer sicheren Betriebsumgebung ausgeführt und stellt die Korrektheit und Integrität importierter und exportierter Daten sicher. Eine Kompromittierung von Daten beim Import oder Export wird zuverlässig verhindert. A.9.2.1, A , A , A , A , A , A , A , A , A , A , A PE-1, PE-18, CM-9, SA-9, AU-4, AU-5, CP-2, SA-2, SC-5, AC-19, AT-2, SA-8, SC-2, SC-3, SC-17, SC-14 SA-11, SC-1, SC-4, SC-5, SC-7, SC-8, SC-9, SI-9, SI-10 [AES-02] Die für den Betrieb erforderliche virtuelle und physikalische Anwendungsumgebung, auf der die Anwendung ausgeführt wird, ist (a) frei von Schadsoftware und Viren, (b) ausreichend gegen interne oder externe netzbasierte Angriffe geschützt und (c) sicher segmentiert (isoliert), so dass eine Eskalation von Zugriffsrechten über die operative Einsatzumgebung ausgeschlossen werden kann. Ein unbefugter und nicht autorisierter Zugriff auf Daten der Anwendung über die operative Einsatzumgebung ist nicht möglich. In der Anwendungsumgebung sind geeignete Werk- A.5.1.1, A.5.1.2, A.6.1.1, A.6.1.3, A.8.1.1, A , A , A , A , A , A , A , A , A , A , A , A , A , AC-1, AC-3, SI-1, SI-3, AC-4, AC-5, SI-4, SI-8, AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AT-2, AU-1, AU-6, AU-7, AU-13, CA-3, CM-5, CP-8, IA-3, PE-5, SA-01, SA-03, 4.2 Tab: SA-05, IS-17 1, 2, 3, Tab: 5 IS-21, IS-34, 4.3 Tab: 1, 2, 3

35 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP CSA CMM V1.4 BSI AC-3(3), AC-6(2), AC-8, AC-17, IA-1, IA-2, IA-3, IA-4, IA-7 AU-10, IS-07, 5 Tab: IS-08, IS-09, 1, 2, 3, 4, IS-10, SA-07, 5 SC-7 SC-2, SC-30, SA-09 zeuge installiert, die zuverlässig imstande sind, das Eindrin- A , A , SA-8, SC-2, gen und die Ausführung von Schadsoftware, Host- bzw. A , A SC-3, SC-7, Netz-basierte Angriffe zu entdecken und zu verhindern. SC-8, SC-9, SC-10, SC-14, SC-19, SC-20, SC-21, SC-22, SC-23, SI-1, SI-1, SI-3, SI-7, PE-6, PE-8, SC-7, SI-4, SP [AES-03] Die Anwendung setzt eine sichere Identifikation und Authentisierung externer Zugriffe durch. Ein Zugriff auf Informationen oder Daten der Anwendung ist nur für zuverlässig und sicher authentisierte und autorisierte Nutzer oder andere Anwendungen oder Services möglich. Unbefugte Zugriffsversuche auf die Anwendung oder Anwendungsdaten bleiben nicht unentdeckt. A , A , A , A , A , A , A , A , A , A , A , A , A , A , A , A AC-1, AC-2, AC-3, AC-6, AC-7, AC-8, AC-9, AC-10, AC-14, AC-21, AU-1, AU-2, AU-3, AU-4, AU-5, AU-6, AU-7, AU-8, AU-11, AU-12, CM-5, IA-5, PE-1, PE-2, PE-1, PE-2, PE-6, PE-8, SC-9, SI-9, SC-10, SI-14 [AES-04] Mandanten und Anwendungen und die ihnen zu- A , A , AC-1, AC-3, Tab:

36 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP CSA CMM V1.4 gewiesenen virtuellen und physikalischen Ressourcen (Net- A , A , AC-5, AC-6, SC-32 ze, Server, Speicher) sind sicher segmentiert und isoliert. A , A , AC-17, AC-18, A AC-20, MA-3, MA-4, PE-3, SA-1, SA-2, SA-8, SC-4, SC-7, SC-30, SC-32 [AES-05] Die Anwendung ist so in die Anwendungsumgebung integriert, dass eine Umgehung von der Anwendungsumgebung bereitgestellter Sicherungsmaßnahmen nicht stattfinden kann. A , A , A , A , A , A , A , A AC-3, AC-4, AC-6, AC-17, AC-18, AC-20, CA-3, CP-8, PE-5, IA-8, SC-7, SC-8, SC-9, SC-10, SC-19, SC-20, SC-21, SC-22, SC-23 [AES-06] Verbindungen zwischen logischen oder auch physisch voneinander getrennten Komponenten kommen erst nach einer sicheren wechselseitigen Authentisierung zustande. Die Identifikation und Authentisierung wird durch zuverlässige und eindeutige Sicherheitsattribute durchgesetzt. Ein unentdeckter Austausch von Sicherheitskomponenten des Service ist nicht möglich. A.7.2.2, A , A , A , A , A , A , A , A AC-3, AC-4, CM-2(5)(a), AC-6, AC-16, CM-7, SC-7 AC-17, AC-18, AC-20, CA-3, CP-8, IA-8, PE-5, SC-7, SC-8, SC-9, SC-10, SC-19, SC-20, SC-21, SC-22, SC-23 [AES-07] Die Anwendung und die Anwendungsumgebung A.5.1.1, A.5.1.2, 36 CM-1, CM-2, CM-1,CM-3, BSI Tab: 2 SA Tab: 5, 7, 8, Tab:

37 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 wird auf der Grundlage ausführlicher Richtlinien und Handlungsanweisungen sicher konfiguriert und betrieben. Ein unbefugter Zugriff auf Daten, die für die Konfiguration und den Betrieb der Anwendungsumgebung erforderlich sind, ist nicht möglich. A.6.1.1, A.6.1.3, CM-6, CM-9 A.7.1.1, A.7.1.2, A.8.1.1, A , A , A , A , A , A , A , A , A , A , A [AES-08] Konfigurationsänderungen oder Updates werden nur von erfahrenen und ausdrücklich autorisierten Mitarbeitern des Cloud-Service-Anbieters durchgeführt und werden (a) kontrolliert und dokumentiert, (b) vor Inbetriebsetzung auf Sicherheitsbedrohungen getestet. Die Tests werden ausführlich zu protokolliert, die Testprotokolle vor Verlust oder die Manipulation geschützt. A.5.1.1, A.5.1.2, A.6.1.1, A.6.1.3, A.8.1.1, A , A , A , A , A , A , A , A , A , A , A , A , A FedRAMP CM-6, SA-7 37 A.5.1.1, A.5.1.2, A.6.1.1, A.6.3.1, A.8.1.1, A.9.2.4, A , A , CM-1, CM-3, CM-5, CM-6, CM-4, CM-5, CM-7, CM-9 CM-9, SA-10, SI-2 AC-5, AC-6, CM-1, CM-2, CM-3, CM-4, CM-5, CM-9, BSI 5, 6 5 Tab.: 1 [AES-09] Sicherheitslücken der Anwendung oder Anwen- A , A , CM-1, CM-2, dungsumgebung werden unverzüglich geschlossen und A , A , CM-3, CM-4, vorhandene Sicherheitspatches unverzüglich implemen- A CM-5, CM-9, tiert. IR-1, IR-4, PL-4, SI-2, RA-3, RA-5, SA-6, SA-7, SI-2, SI-5 [AES-10] Der Cloud-Service-Anbieter etabliert und implementiert sichere Prozesse für die Administration und Wartung der Anwendung und Anwendungsumgebung. Administration und Wartungsmaßnahmen dürfen nur von ver- CSA CMM V1.4 MA-6 RM-02, 4.4 Tab: RM-03, 6, 7 RM-04, RM-05, RS-01, RS-02 IS Tab: 6 OP-02, OP-04 3 Tab: 1, 2 5 Tab:

38 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Netzsicherheit (Network Security - NCS) 38 Sicherheitsanforderung ISO 27001:2005 NIST rev3 trauenswürdigen, erfahrenen und ausdrücklich autorisierten Mitarbeitern ausgeführt werden. Für die Administration und Wartung der Anwendung und der Anwendungsumgebung stehen ausführliche Dokumentationen, Richtlinien oder Handreichungen zur Verfügung, die von den Administratoren und dem Wartungspersonal strikt befolgt werden. Die Maßnahmen werden ausführlich zu protokolliert und die Protokolle vor Verlust und Manipulation geschützt. A , A , A , A , A , A , A,11.6.1,A , A , A , A , A , A MA-1, MA-2, MA-3, MA-5, PL-4, SA-6, SA-7, SA-10, SI-2, SI-7, SI-9, SI-10 [AES-11] Der Cloud-Service-Anbieter hat sichere Prozesse für die Überwachung des Softwarelebenszyklus der Anwendung etabliert und implementiert. Neue Releases werden erst eingesetzt werden, wenn sie qualitätsgesichert und ausführlichen Sicherheitstests unterzogen wurden. A , A , SA-3, SA-5, A , A , SA-7, SA-8, A , A , SA-10 A , A , A A , A , A FedRAMP CSA CMM V1.4 BSI 1, 3 7 Tab: 6 11 Tab: 1 CP-4a, SA-3, SA-5, SA-7, SA-8, SA-10, SA-11 IS-33, RM-01, 4.4 Tab: RM-02, 1, 6, 7 RM-03, RM-05 [AES-12] Der Cloud-Service-Anbieter garantiert die Einhal- A , A , SA-3, SA-8 tung von Sicherheits-Mindeststandards bei der Entwicklung A , A , und Bereitstellung von Web-Anwendungen (beispielsweise A gemäß den Prinzipien zur sicheren Softwareentwicklung nach OWASP) SA-04 [NCS-01] Netzarchitekturen sind so entworfen, implementiert und konfiguriert, dass Verbindungen zwischen sicheren und unsicheren Netzen nicht möglich sind. Telekommunikations- und Netzverbindungen für den Datentransport, die Kommunikation zwischen logisch oder physische separierten Komponenten oder Ressourcen und den Servicesupport sind vor Abhören, Manipulation und Zerstörung geschützt. Virtualisierte Netzwerkkomponenten (Verbindungen, Router und Switches) sind zuverlässig und sicher segmentiert und isoliert. IS-31, RS-08, 4.3 Tab: SA-08, SA-09, 1, 2, 3, 6, SA-11 7 A.6.2.1, A , A , A , A , A , A , A , A , A , A AC-4, AC-17, AC-17(8), AC-18, AC-20, SC-7, SC-8, CA-3, CP-8, SC-9 PE-5, SC-7, SC-8, SC-9, SC-10, SC-11, SC-19, SC-20, SC-21, SC-22, SC Tab: 3

39 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP CSA CMM V1.4 BSI [NCS-02] Der Cloud-Service-Anbieter stellt auf der Grundlage ausführlicher Richtlinien und Handlungsanweisungen die sichere Konfiguration und Segmentierung von Netzkomponenten sicher. Management-Netze (ManagementInterfaces) sind strikt von Datennetzen getrennt. A.5.1.1, A.5.1.2, A.6.1.1, A.6.1.3, A.6.2.1, A.7.1.1, A.7.1.2, A.8.1.1, A , A , A , A , A , A , A , A , A , A , A , A , A , A , A , A , A , A CM-1, CM-2, CM-6, CM-9, SA-8, SC-3, SC-4, SC-7, SC-32 SC-7(13), SC-11 IS-31, IS Tab: 4 [NCS-03] Die Fernadministration des Service erfolgt über einen sicheren Kommunikationskanal (z. B. SSH, IPSec, TLS/SSL, VPN). Der Ausfall oder die Kompromittierung von Management-Netzen (Management-Interfaces) wird zuverlässig verhindert. [NCS-04] Die Konfiguration der Netzkomponenten wird nur von erfahrenen und ausdrücklich autorisierten Mitarbeitern des Cloud-Service-Anbieters ausgeführt. Änderungen an der Konfiguration von Netzkomponenten werden vor Inbetriebnahme ausführlichen Sicherheitstests unterzogen. Die Tests werden protokolliert, die Protokolle vor Verlust oder Manipulation geschützt. A.5.1.1, A.5.1.2, A.6.1.1, A.6.1.3, A.8.1.1, A , A , A , A , A , A , A , A , A , A , A , A , A [NCS-05] Im Falle verteilter Cloud-Computing-Ressourcen A.5.1.1, A.5.1.2, 39 SC Tab.: 6 CM-1, CM-3, CM-4, CM-5, CM-9, SA-10, SI-2 5 Tab: 2 CP-1, CP-2 CP-1, CP-2, 4.3 Tab:

40 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 sind die Netzverbindungen zwischen den Rechen- oder Da- A.6.1.1, A.6.1.2, tenzentren redundant ausgelegt. A.6.1.3, A.8.1.1, A.9.1.4, A , A , A , A , A , A , A , A , A , A CSA CMM V1.4 CP-8 Datenschutz und Datensicherheit [DSS-01] Der Cloud-Service-Anbieter gewährleistet die Ein- A , A , AC-2,AC-8, haltung der für den Cloud-Service-Abonnenten geltenden A , A , AU-6, AU-9, A , A AU-11, CA-2, (Data Safety and Security - datenschutzrechtlichen Regelungen. CA-7, IA-7, DSS) CP-9, MP-1, MP-4, PL-5, PE-8, PL-4, PS-6, PS-8, SA-5, SA-6, SA-7, SI FedRAMP [DSS-02] Daten des Cloud-Service-Abonnenten werden au- A , A , ßerhalb der am Standort geltenden Gerichtsbarkeit nur mit A ausdrücklicher, schriftlicher Zustimmung des Cloud-Service-Abonnenten erfasst, verarbeitet und gespeichert. Das betrifft auch die Verarbeitung und Speicherung von Daten des Cloud-Service-Abonnenten durch Sub-Dienstleister des Cloud-Service-Anbieters. AC-8, AU-6, AU-9, AU-11, CP-9, MP-1, MP-4, SA-5, PL-4, PL-5, PS-6, PS-8, SA-7, SI-12 [DSS-03] Personenbezogene Daten des Cloud-Service- A Abonnenten sind nach Maßgabe zu erwartender Bedrohungen - unter keinen Umständen unbefugten Dritten zugänglich. PL-5; SI-12 BSI 10 DG-02, DG Tab: 1, 2, 3, 4, Tab: 1, Tab: 2, 3, 4 DG Tab: 1

41 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 [DSS-04] Administratoren, Wartungspersonal oder andere A , A Mitarbeiter des Cloud-Service-Anbieters sowie seines SubDienstleisters haben keinen Zugriff auf geschäftsbezogene Daten des Cloud-Service-Abonnenten. 41 NIST rev3 FedRAMP CSA CMM V1.4 AC-8, AU-6, PL-4, PL-5, PS-6, PS-8, SA-7, SI Tab: 1 [DSS-05] Ein unwiederbringlicher Verlust oder ein Diebstahl A5.1.1, A5.1.2, AC-1, AC-3, von Daten des Cloud-Service-Abonnenten wird durch ge- A.6.1.1, A.6.1.3, AU-4, CP-6, eignete Sicherheitsmaßnahmen zuverlässig verhindert. A.8.1.1, A.9.1.4, CP-10 A10.1.1, A , A , A , A , A11.2.2, A11.4.1, A , A , A , A , A , A , A , A ,A , A , A CP-9 [DSS-06] Der Cloud-Service-Anbieter gewährleistet eine re- A.9.1.4, A , CP-6, CP-9, gelmäßige, transparente und redundante Sicherung von An- A , A , CP-10 wendungs- und anwendungsbezogenen Daten. A CP-9 [DSS-07] Datenträger, auf denen Daten und Informationen des Cloud-Service-Abonnenten aufbewahrt werden, werden regelmäßig auf korrekte Funktion geprüft sowie vor Verlust und Zugriff unbefugter Dritter geschützt. MP-1, MP-2, MP-4, MP-5, MP-6 A.5.1.1, A.5.1.2, MP-1, MP-2, A.6.1.1, A.6.1.3, MP-4, MP-5, A.7.2.2, A.8.1.1, MP-6 A.9.2.5, A.9.2.6, A.9.2.7, A , A , A , A , A , A , A , A , A , A BSI DG-04, DG-05, DG Tab: Tab: 3

42 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP [DSS-08] Der Cloud-Service-Anbieter stellt die vollständige und nicht wiederherstellbare Löschung von Daten des Cloud-Service-Abonnenten bei Vertragsende oder auf Anforderung des Cloud-Service-Abonnenten sicher. [DSS-09] Ein Zugriff auf die Anwendung und Anwendungsdaten von mobilen Endgeräten erfolgt nur über sichere Kanäle und in Übereinstimmung mit den Sicherheitsrichtlinien des Cloud-Service-Abonnenten. [PKI-01] Die Kommunikation zwischen Cloud-ServiceAnbieter und Cloud-Service-Abonnenten, Cloud-Compu(Public Key Infrastructure - ting Standorten sowie Drittdienstleistern erfolgt verschlüsselt. PKI) Verschlüsselung und Schlüsselmanagement A , A , AC-18, A , A , AC-19, A , A , A , A , A , A , A , A A10.4.1, A , A , A , A , A , A , A , A CSA CMM V1.4 BSI DG Tab: 4 AC-18, AC-19 IS-32, SA-10, 4.4 Tab: SA-15 (1), (2), (4), (7) AC-1, AC-3, IA-7, SC-11 AC-4, AC-17, AC-18, AC-19, AC-20, AT-2, CA-3, PL-4, PS-6, SA-8, SA-9, SC-2, SC-3, SC-7, SC-8, SC-9, SC-11, SC-14, SC-16, SI-3, SI-7, SI-9 IS-18 [PKI-02] Der Cloud-Service-Anbieter stellt ausreichend star- A , A , SC-12, SC-13 SC-12, SC-13 IS-18, IS-19 ke und standardisierte kryptografische Sicherheitsmaßnah- A men und Services zur Verfügung, mit denen (a) eine unbefugte Kenntnisnahme oder Manipulation von Daten, Anwendungen, Komponenten und Services verhindert werden kann und (b) die Korrektheit, die Integrität und Authentizität importierter und exportierter Daten zuverlässig gewähr Tab: 7, 8, Tab: 1

43 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP CSA CMM V1.4 BSI leistet wird und eine mögliche Aufdeckung oder Kompromittierung beim Import und Export verhindert werden kann. [PKI-03] Für den kryptografischen Schutz bewegter Daten A , A SC-13 (data in transit) und gespeicherter Daten (data at rest) sowie Kommunikationsverbindungen werden ausschließlich vertrauenswürdige kryptografische Komponenten eingesetzt. AU-10(5), IA-7, SA-4, SC Tab: 1 [PKI-04] Die Erzeugung, Verwaltung, Verteilung und Spei- A , A , SC-12, SC-13 SC-12(5), cherung kryptografischen Materials wird nur in sicheren A SC-17 Umgebungen ausgeführt. Der Zugang zur Administration kryptografischen Materials erfordert eine separate Autorisierung. Kryptografische Materialien dienen ausschließlich einem Verwendungszweck. ID- und Rechtemanagement (ID and Rights Management - IDM) 43 [PKI-05] Eine unbefugte Kenntnisnahme oder Kompromit- A tierung sowie ein Verlust kryptografischen Materials wird nach Maßgabe zu erwartender Bedrohungen - zuverlässig verhindert. SC 12, SC-17 [IDM-01] Der Cloud-Service-Anbieter stellt sicher, dass Zugriffe auf die Anwendung und Anwendungsumgebung nur auf der Basis eines sicheren Identitätsmanagements, Rollenund Rechtekonzepts, einer starken Authentisierung und einer strikten Trennung von Aufgaben und Zuständigkeiten (separation of duties) erfolgen können. AC-5, AU-1, AC-16, AU-2, AU-3, IA-2(8), AU-4, AU-5, IA-4e, AU-6, AU-7, AU-8, AU-11, AU-12, AC-1, AC-2, AC-3, AC-6, AC-7, AC-8, AC-9, AC-10, AC-14, AC-21, CM-5, A , A , A , A , A , A , A , A , SC Tab: 1 IS Tab: 1 SA-01, SA-02, 5 Tab: 1, 2, 3, 4, 5

44 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP CSA CMM V1.4 BSI IA-2, IA-6, IA-8, PE-1, PE-2, PE-6, PE-8, SC-7, SC-10, SI-9, SI-4 [IDM-02] Die Umsetzung und Einhaltung des Identitätsma- A nagements und die Wirksamkeit der implementierten Maßnahmen werden regelmäßig überprüft. AC-2, PE-2 5 Tab: 2 [IDM-03] Ein Diebstahl oder die Fälschung von Identitäten oder Zugriffsrechten wird, mit Blick auf erwartbare Bedrohungsszenarien, zuverlässig verhindert. 5 Tab: 1, 2, 3, 4, 5 [IDM-04] Mitarbeiter erhalten Zugriff nur auf die Funktio- A.6.1.3, A.8.1.1, AC-6 nen, die sie für sie Erfüllung ihrer Aufgaben (ihrer Rolle) be- A , A , nötigen (least privilege). A , A , A , A , A , A AC-6 5 Tab: 3 [IDM-05] Eine Eskalation von Zugriffsrechten wird, mit Blick auf erwartbare Bedrohungsszenarien, zuverlässig verhindert. Kritische Administrationsaufgaben, wie die Einspielung von Sicherheitspatches oder die Änderung von sicherheitskritischen Konfigurationsdaten werden besonders geschützt. AC-3, AC-5, AC-6 5 Tab.: 4 A.6.1.3, A.8.1.1, AC-3, AC-5, A , A , AC-6 A , A , A , A , A , A , A , A [IDM-06] Die Zugriffe werden protokolliert. Die Protokolle A.6.2.2, A.8.1.1, AC-8, AC-9 werden vor Verlust und Manipulation geschützt. A , A Kontrollmöglichkeiten für 44 [UIC-01] Die Verfügbarkeit der Anwendung, die Performanz 4.3 Tab: 5, 6 AC-7 7 Tab: 2 7 Tab:

45 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP CSA CMM V1.4 und die Auslastung werden ausreichend und transparent protokolliert. Die Protokolle sind vor Verlust und (User Information Control Manipulation geschützt. UIC) 2, 5 den Nutzer [UIC-02] Der Cloud-Service-Abonnent hat die Möglichkeit haben Monitoringinformationen hinsichtlich der Verfügbarkeit, Performanz und Auslastung über definierte Schnittstellen regelmäßig abzufragen. Monitoring und Security Incident Management (SIM) 45 BSI 6 Tab: 1 [SIM-01] Der Cloud-Service-Anbieter hat ein zuverlässiges Monitoring für das Konfigurationsmanagement etabliert und implementiert. Diesbezügliche Aktivitäten von Administratoren werden überwacht und protokolliert. Die Protokolle werden vor Verlust und Manipulation geschützt. SC-5, SI-4(5) IS-30 7 Tab: 1, 2 [SIM-02] Der Cloud-Service-Anbieter verfügt über klare A.5.1.1, A.5.1.2, AU-9, IR-1, Richtlinien sowie etablierte und bewährte Prozesse für die A.6.1.1, A.6.1.3, IR-4, IR-5, Behandlung sicherheitskritischer Ereignisse. A.8.1.1, A , IR-8, A , A , A , A , A , A , A , A , A IR-1, IR-3, IR-4, IR-6, IR-7, IR-8b, IR-8e IS-22, IS-23, IS-24, IS-25 7 Tab: 1, 3 [SIM-03] Der Cloud-Service-Anbieter stellt die kontinuierliche (24/7) Erkennung, Identifikation und eine unverzügliche und angemessene Behandlung (Einleitung von Gegenmaßnahmen) sicherheitskritischer Ereignisse (security impacts) durch ein erfahrenes und handlungsfähiges Team und geeignete technische Maßnahmen sicher. IR-6, IR-7, IR-8 SA-14 A.5.1.1, A.5.1.2, IR-1, IR-2, A.6.1.1, A.6.1.2, IR-3, IR-4, A.6.1.3, A.8.1.1, IR-5, IR-7 A.8.2.2, A , A , A , A , A , A , A Tab: 1 7 Tab: 1, 2, 3

46 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 [SIM-04] Sicherheitskritische Ereignisse werden dem Cloud- A.6.1.6, A Service-Abonnenten zur Kenntnis gebracht sowie umfassend, ausführlich und transparent dokumentiert. Die Dokumentation wird vor Verlust und Manipulation geschützt und auf Verlangen dem Cloud-Service-Abonnenten vorgelegt. Notfallmanagement (Business Continuity Management - BCM) [BCM-01] Der Cloud-Service-Anbieter hat ein zuverlässiges und sicheres Notfallmanagement etabliert und implementiert. Die darin definierten Maßnahmen und Prozesse werden regelmäßig auf ihre Funktion und Wirksamkeit überprüft. Der Cloud-Service-Anbieter sollte nachweisen, dass sein Notfallmanagement auf international anerkannten Standards wie z. B. BS (heute ISO 22301) oder BSIStandard basiert (z. B. anhand Notfallvorsorgekonzept und Notfallhandbuch). NIST rev3 FedRAMP CSA CMM V1.4 BSI IR-6 IR-6 IS-23, IS-25 7 Tab: 4, 5, 6 A.5.1.1, A.5.1.2, CP-1, CP-2, A.6.1.1, A.6.1.2, CP-3, CP-4, A.6.1.3, A.8.1.1, PM-9 A.8.2.2, A.9.1.4, A , A , A , A , A , A , A , A , A , A [BCM-02] Eine Störung oder ein Ausfall der Verfügbarkeit A.9.1.4, A , CP-6, CP-7, wird durch eine redundante Auslegung und dynamische A , A , CP-8, CP-9 Bereitstellung zusätzlicher Instanzen sowie virtueller und A physischer Ressourcen verhindert. CP-2b, CP-2f, OP-03, 8 Tab: CP-9, RS-03, RS-04, 1, 2, 3, 4 CP-10(3), PE-10b, PE-14a CP-9, PE Tab: 1, Tab:10 8 Tab: 1, 2 [BCM-03] Die Anwendung kann bei einem Systemfehler A.9.1.4, A oder einem erfolgreichen Angriff wieder in einen sicheren und stabilen Zustand zurückgeführt werden. [BCM-04] Störungen der Verfügbarkeit, die Maßnahmen zur Wiederherstellung und die Zeitdauer der Störung werden zuverlässig und transparent protokolliert, die Protokolle vor 46 CP-10 7 Tab: 2

47 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP CSA CMM V1.4 BSI Verlust und Manipulation geschützt. Portabilität und Interoperabilität (Portability and Interoperability Management - PIM) Sicherheitsüberprüfung und -nachweis (Security Compliance Management - SCM) [PIM-01] Die Anwendung ist kompatibel und interoperabel A , A , mit den Systemen (Anwendungen) des Cloud-ServiceAbonnenten und auf der Basis akzeptierter und marktgängiger (Sicherheits-) Standards implementiert. 9 Tab: 1, 2 [PIM-02] Datenformate für den Austausch, die Verarbeitung und Speicherung von Daten basieren auf international anerkannten Standards. Der Cloud-Service-Anbieter stellt die Plattformunabhängigkeit für den Austausch und die Speicherung von Daten sicher. 9 Tab: 1, 2 [PIM-03] Schnittstellen für den Datenaustausch und die Datenspeicherung sind durch den Cloud-Service-Anbieter offen gelegt. 9 Tab: 2 [SCM-01] Der Cloud-Service-Anbieter führt regelmäßige Sicherheitsrevisionen/Audits (Überprüfung von Sicherheitskonzepten, Sicherheitsrichtlinien, Sicherheitsarchitekturen und Sicherheitsmaßnahmen, Erkennung und Behandlung sicherheitskritischer Ereignisse) auf der Basis international anerkannter und akzeptierter Standards durch. Das gilt auch für die von ihm vertraglich für die Erstellung des Service gebundenen Sub-Dienstleister A.5.1.1, A.5.1.2, AU-1, AU-2, AU-2d, A.6.1.1, A.6.1.3, AU-3, AU-12, AU-3(1), A.8.1.1, A , PL-6 CA-6c A , A , A , A , A , A , A [SCM-02] Die Prüfergebnisse werden ausführlich dokumen- A tiert und vor Verlust und Manipulation geschützt. [SCM-03] Unabhängige Auditoren führen regelmäßig Revi47 AC-2, CA-2, CA-7, IA-7, PE-8, RA-5, SI-12 AU-1, AU-7, AU-11 AU-9, AU-11, PL-6 CO-01, 3 Tab: CO-02, 3 CO-03, 10 Tab: CO-05, IS-29 1, 2, 3, 4, 5 3 Tab: 4 10 Tab:

48 Teil 1: Sicherheitsanforderungen BSI Eckpunktepapier Sicherheitsanforderung ISO 27001:2005 NIST rev3 FedRAMP sionen durch. Der Cloud-Service-Abonnent kann die Dokumentation der Revisionen auf Verlangen einsehen. Anforderungen an das Personal (Human Resource Requirements - HRR) 48 CSA CMM V1.4 BSI 4, 5 [HRR-01] Mitarbeiter des Cloud-Service-Anbieters und der A an der Bereitstellung des Service beteiligten Sub-Dienstleiter werden regelmäßig zu Sicherheitsbedrohungen und Sicherheitsmaßnahmen ausreichend geschult. AT-1, AT-2, AT-3, AT-4, IR-2 AT-1, AT-2, AT-3, AT-4 HR-01, IS-11, 11 Tab: IS-12, IS-14 2, 3 [HRR-02] Die Mitarbeiter werden regelmäßig einer Sicherheitsüberprüfung unterzogen und auf die Einhaltung der Bewahrung von Betriebsgeheimnissen von Cloud-ServiceAbonnenten verpflichtet. Mitarbeiter, die Zugang zu Anwendungs- oder Konfigurationsdaten haben, werden in besonderem Maße auf ihre Pflichten im Umgang mit diesen hingewiesen. PS-1, PS-2, PS-3, PS-4, PS-5, PS-6, PS-7, PS-8 PS-1, PS-2, PS-3, PS-4, PS-5, PS-6, PS-7, HR-01, 11 Tab: HR-02, 1, 4 HR-03, LG-01, LG-02 A.5.1.1, A.5.1.2, A.6.1.1, A.6.1.3, A.6.1.5, A.8.1.1, A.8.1.2, A.8.1.3, A.8.2.1, A.8.2.3, A.8.3.1, A.8.3.2, A.8.3.3, A , A , A ,

49 Bedrohungs- und Risikoanalyse Teil 2: Teil 2: 2.1 Bedrohungs- und Risikoanalyse Einleitung Die Nutzung eines als Software-as-a-Service (SaaS) bereitgestellten elektronischen Archivs bedeutet für den Cloud-Service-Abonnenten die Beauftragung eines Dritten mit der Bereitstellung erforderlicher Rechenund Speicherkapazitäten für die Aufbewahrung von Unternehmensdaten in einem aus Sicht des Serviceabonnenten virtuellen Datencenters. Ein Verlust, eine Manipulation, eine unbefugte Kenntnisnahme dieser Daten durch Dritte kann zu einer erheblichen Beeinträchtigung der Geschäftsfähigkeit des Unternehmens und in der Folge auch zu einem erheblichen Ansehens- und Vertrauensverlust sowohl auf seiten des CloudService-Abonnenten wie auch des Cloud-Service-Providers führen. Vor diesem Hintergrund wurden in Teil 1 dieses Dokuments - Sicherheitsanforderungen - der Schutzbedarf hinsichtlich Vertraulichkeit und Integrität sowohl für die Unternehmensdaten wie auch für die Nutzerkontodaten des Cloud-Service-Abonnenten als hoch eingestuft. Für den Cloud-Service-Provider erwächst hieraus die Verantwortung, durch geeignete technische und orga nisatorische Maßnahmen dafür Sorge zu tragen, dass eine unbefugte Kenntnisnahme, eine Manipulation oder auch ein Verlust der ihm anvertrauten Daten nach Maßgabe zu erwartender Gefährdungen zuverlässig ausgeschlossen und das SaaS Archivsystem mit der vereinbarten Leistungsgüte bereitgestellt werden kann. In diesem Dokument werden Bedrohungen für das Einsatzszenario elektronische Archivierung als SaaS in einer Cloud Computing Umgebung nach dem STRIDE-Modell beschrieben. Dafür wird das Akteursmodel aus dem ersten Teil zur Grundlage genommen und für die involvierten Komponenten, Akteure und Verbindungen Bedrohungen nach STRIDE ermittelt. STRIDE ist ein Akronym und steht für Spoofing (nachahmen, Vortäuschen einer Identität), Tampering (fälschen, manipulieren von Daten), Repudiation (Abstreiten einer Handlung), Information Disclosure (aufdecken, veröffentlichen von Informationen), Denial of Service (Dienstverweigerung) und Elevation Privilege (unzulässige Erweitering von Rechten). STRIDE wurde 2002 von Microsoft für die Klassifizierung von Angriffsmustern entwickelt. Tabelle 3: Bedrohungen und Sicherheitseigenschaften27 Bedrohung Sicherheitseigenschaft Spoofing Authentifizierung Tampering (Datenmanipulation) Integrität Repudiation (Abstreitung) Nichtabstreitbarkeit Information disclosure (Veröffentlichung von Informationen) Vertraulichkeit Denial of Service (Dienstverhinderung) Verfügbarkeit Elevation of Privilege (Rechteerweiterung) Autorisierung Das Angriffsmuster Spoofing zielt vor allem auf Schwachstellen in der Authentifizierung. Tampering fokussiert vornehmlich auf die Veränderung (Manipulation) von persistenten Daten, wie Log-Dateien, oder Angriffen auf die Integrität von Daten, die über Netze transportiert werden. Ziel von Repudiation ist die Verschleierung (Bestreiten) böswilliger oder auch fahrlässiger Handlungen, in einem Archivsystem, beispielsweise die unbemerkte Veränderung der Kennzeichnung (Klassifizierung) von Daten, was ggf. die Löschung 27 Quelle: Hernan, S., Lambert, S., Ostwald, T., Shostack, A.: Aufdecken von Fehlern im Sicherheitsentwurf mithilfe des STRIDE-Ansatzes, abgerufen unter am

50 Teil 2: Bedrohungs- und Risikoanalyse oder das Überschreiben der Daten zur Folge hat. Information Disclosure bezeichnet nicht autorisierte Zugriffe auf Datenbanken oder die Weitergabe von Kundendaten. Zu den Denial of Service Angriffen gehören die Überlastung netzbasierter Infrastrukturen oder auch die Manipulation von Konfigurationsdaten, mit dem Ziel eine Störung oder einen Ausfall der Verfügbarkeit eines Dienstes, hier des Archivsystems herbeizufüh ren. Elevation of Privilege klassifiziert Angriffe, die bspw. mittels Buffer-Overflows oder SQL-Injections darauf abzielen, eigene Berechtigungen im Umgang mit dem Archivsystem zu erhöhen. Die folgende Tabelle ordnet Bedrohungen den Eigenschaften zu, die davor schützen. Auf der Grundlage der STRIDE Klassifikation wird in den Anlagen zu diesem Dokument in Form von Steck briefen exemplarisch aufgezeigt, wie eine Bedrohungs- und Risikoanalyse für die Akteure, Komponenten und Kommunikationsverbindungen eines als SaaS bereitgestellten Archivsystems unter Berücksichtigung des IETF Cloud Computing Stack durchgeführt wird. Darüber hinaus werden Restrisiken und Bereiche für detailliertere Untersuchungen benannt, die Gegenstand für weitere Analysen sein sollten. Rein kombinatorisch ergeben sich aus den vier Cloud-Komponenten (Access & Delivery Layer, Cloud Service Layer, Cloud Management Layer, Ressource Assignment), den internen und externen Kommunikationsverbindungen und den 6 STRIDE-Kategorien 6*6=36 Risiken, die für die vier Akteure (Subsciber End User, Subscriber User Admin, CSP Admin, Sub-Provider) insgesamt 4*36=144 Risikoausprägungen ergeben. Einige von den Ausprägungen fallen jedoch weg, da bestimmte Akteure nicht auf alle Komponenten zugreifen können. Auf Grundlage der folgenden Überlegungen werden die Risiken (und 120 Risikoausprägungen) noch weiter konsolidiert: Für dieses Dokument wird davon ausgegangen, dass der Abonnent (in den verschiedenen Rollen als Benutzer und Administrator) ein eigenes ISMS betreibt. Daher werden die gemäß STRIDE klassifizierten Bedrohungen bei ihm hier nicht näher betrachtet. STRIDE Angriffsmuster der externen Kommunikationswege lassen sich, bis auf die Verfügbarkeit durch den Internet-Service-Provider, alle auf die nach STRIDE klassifizierten Bedrohungen des Access und Delivery Layer zurückführen und werden dort mit betrachtet (verbleiben 5*6+1=31 Risiken). Die gemäß STRIDE klassifizierten Bedrohungen der internen Kommunikationswege lassen sich alle (bis auf Verfügbarkeit) auf STRIDE Angriffsmuster der internen Komponenten abbilden und werden dort mit betrachtet. Da Verfügbarkeit von externen und internen Verbindungen das gleiche Risiko ist, werden beide Risiken zusammen betrachtet (verbleiben 4*6+1=25 Risiken). Grundsätzlich lässt sich die Abstreitung von Handlungen durch Logging und Monitoring der jeweiligen Komponenten erledigen. Daher wird die Abstreitung nur einmal betrachtet (verbleiben 4*5+1+1=22 Risiken). Die Bedrohungen von Sub-Providern bzw. Ketten von Sub-Providern und die damit einhergehenden Risiken können, mit einer entsprechenden Vertragsgestaltung, auf die Sub-Provider übertragen werden. Die Bedrohungen nach STRIDE im Cloud Service Layer bedingen, dass zuvor eine Bedrohung im Access und Delivery Layer eingetreten ist. Dessen ungeachtet, stellen die Manipulation (Tampering), die auch die Rechteeskalation als einen besonderen Fall der Manipulation umfasst, und Information Disclosure durch ungenügende oder fehlerhafte Mandantentrennung hier ernsthafte Bedrohungen dar (verbleiben 3* =19 Risiken). Im Cloud Management Layer werden auch die Sicherheitsdienste des Cloud Providers selbst verwaltet. Daher sind hier besonders die Manipulation und die Rechteeskalation wichtig. Da ein Archivsystem besonders von Speicherressourcen abhängig ist, die hier mit gesteuert werden (ggf. auch durch Einbindung anderer Cloud-Dienstleister), wird die Diensteverweigerung (DoS) hier besonders betrachtet. Da DoS dann sowohl bei den Kommunikationsverbindungen als auch in der Ressourcenkontrolle betrachtet wird, erübrigt sich die zusätzliche Betrachtung im Access und Delivery Layer. Bei einem Archivsystem ist die Verwaltung und Steuerung der (physischen und virtuellen) Ressourcen aus Sicherheitssicht besonders wichtig. Daher werden für das Ressource Controll-Layer bis auf Spoofing und Repudiation alle STRIDE-Risiken betrachtet. Daher ist es nicht nötig, die Risiken Tampering und Elevation of Privilege zusätzlich im Access und Delivery-Layer zu behandeln. Im Access und Delivery Layer werden demnach nur Spoofing, Repudiation und Information Disclosure behandelt (verbleiben =13 Risiken). In diesem Dokument werden dreizehn wichtige Bedrohungen für eine SaaS Archivlösung für die Schichten des IETF Cloud Stacks beschrieben: 50

51 Bedrohungs- und Risikoanalyse Teil 2: für das Access & Delivery Layer: Spoofing, Repudiation, Information Disclosure, für das Cloud Service Layer: Tampering und Information Disclosure für die Cloud Management Plane: Tampering, Denial of Service und Elevation of Privilege für das Cloud Resource & Orchestration Layer: Tampering, Information Disclosure, Denial of Service und Elevation of Privilege, für die Kommunikation des Serviceabonnenten mit der Access & Delivery Layer Denial of Service. Die gemäß STRIDE Klassifikation ausführliche Beschreibung möglicher Bedrohungen für das Access & Delivery Layer, die Cloud Management Plane und das Cloud Resource & Orchestration Layer begründet sich daher vornehmlich aus der Einschätzung, dass es sich hier für eine SaaS Archivlösung um sehr kritische Komponenten handelt, da über diese Komponenten sowohl berechtigte als auch unberechtigte Nutzer und Administratoren Zugriff auf die Cloud Services und Daten nehmen können. Die Bedrohungs- und Risikoanalyse nimmt dabei vornehmlich mögliche Gefährdungen in den Blick, denen die im IETF Cloud Stack benannten Schichten und Komponenten nach heutigem Kenntnisstand ausgesetzt sind. Ziel ist es nicht, mögliche oder auch nur vorstellbare Angriffsszenarien zu beschreiben. In Teil 3 dieses Dokuments werden technische, organisatorische und personelle Maßnahmen beschreiben, die geeignet sind, dem, in diesen zweiten Teil, beschriebenen Bedrohungen angemessen zu begegnen. Eine Bedrohungsund Risikoanalyse für die darunter liegenden Cloud Computing Services, also Platform-as-a-Service (PaaS) und Infrastructure-as-a-Service (IaaS), ist nicht Gegenstand der Betrachtung. 2.2 Bedrohungs- und Risikopotentiale Alljährlich veröffentlicht die Cloud Security Alliance, eine Non-Profit-Organisation mit Mitgliedern weltweit, eine Rangliste von Sicherheitsbedrohungen für Cloud Computing. Nicht alle davon sind neu, die meisten sind schon aus dem klassischen IT-Outsourcing Umfeld bekannt. Neu ist die Anzahl und Wechsel wirkung von Herausforderungen und Risiken für die IT in der Cloud, verursacht vor allem durch die dyna mische Skalierung und die Virtualisierung physischer Ressourcen. Das gilt natürlich auch für Software-as-aService Dienstleistungen. 51

52 Teil 2: Bedrohungs- und Risikoanalyse Die signifikantesten Cloud Computing Bedrohungen Für das Jahr 2013 benennt die Cloud Security Alliance neun sicherheitskritische Bedrohungen für Cloud Computing:28 Tabelle 4: Neun sicherheitskritische Bedrohungen für Cloud Computing STRIDE Klassifikation 1. Dateneinbrüche: ermöglicht durch die ungenügende oder unsichere Information disclosure Trennung von Daten und Anwendungen, eine ungenügende Authentifikation und Autorisierung beim Zugriff auf Daten und Anwendungen, die inkonsistente Nutzung von Verschlüsselungsmaßnahmen oder die Aufdeckung von Schlüsselmaterial, mit dem die Daten in der Cloud gesichert werden sollen. Nach dem Bericht kann die Aufdeckung und der Missbrauch von Schlüsselmaterial auch über virtuelle Maschinen hinweg, die auf demselben physikalischen Server zum Einsatz kommen, nicht ausgeschlossen werden. 2. Datenverlust: durch böswillige Angriffe, fahrlässiges Verhalten des Repudiation Providers, eine ungenügende Absicherung beherrschbarer physischer Ereignisse, aber auch ein unsicherer Umgang des Serviceabonnenten mit Denial of Service Schlüsselmaterial. 3. Account oder Service Traffic Hijacking: durch Fälschung, Diebstahl und Spoofing Missbrauch von Authentifikations- und Autorisierungsdaten Tampering Repudiation Information disclosure Elevation of privilege Unsichere Schnittstellen: Cloud computing stellt den Nutzern eine Reihe komplexer Schnittstellen für das Management des Service zur Verfügung. Dieselben Schnittstellen werden ggf. auch durch den Serviceprovider für die Bereitstellung, das Management, die Orchestrierung und Überwachung der Dienstleistung und die Inanspruchnahme von Dienstleistungen Dritter genutzt. Unsichere Authentisierungs- und Autorisierungsmaßnahmen, unzureichendes Monitoring und Protokollierung (logging) der Nutzung dieser Schnittstellen oder auch unbekannte, unentdeckte Abhängigkeiten bedrohen die Vertraulichkeit, Integrität und Verfügbarkeit der Anwendung. Tampering Repudiation Information disclosure Elevation of privilege Dienstverhinderung: durch Distributed Denial of Service (DDoS) Attacken, Denial of Service aber auch zunehmend asymmetrische Angriffe auf Schwachstellen von Webservern, Datenbanken oder anderen Cloud Ressourcen abgerufen am

53 Bedrohungs- und Risikoanalyse Teil 2: STRIDE Klassifikation 6. Böswillige Insider: die Schadenswirkungen durch böswillige Aktionen von Mitarbeiten des Cloud Dienstleister werden verstärkt durch die Konvergenz von IT-Dienstleistungen seitens des Providers und der Servicekonsumenten unter einer gemeinsamen Managementdomäne sowie dem generellen Mangel an Transparenz der Prozesse und Abläufe des Dienstleisters. Unzureichende Sicherheitsüberprüfungen oder Zugriffskontrollen auf sicherheitskritische Bereiche steigern die Attraktivität der Möglichkeiten interner Angriffe nicht nur für Hobbyhacker. Spoofing Tampering Information disclosure Elevation of privilege 7. Missbrauch: durch ungenügende oder unsichere Registrierungsprozesse Spoofing sowie eine unzureichende Überwachung des Netzverkehrs und der Nutzung von Cloud Dienstleistungen. Cloud Provider bieten ihren Kunden Information disclosure die Hoffnung auf unbegrenzte Rechenleistung, Netz- und Speicherkapazität in Kombination mit einem reibungslosen Anmeldeprozess. Jedermann mit einer gültigen Kreditkarte kann sich registrieren und sofort beginnen, die Cloud Dienstleistung zu nutzen. Der mögliche Missbrauch relativer Anonymität in Kombination mit der Nutzung gemeinsamer Ressourcen durch unterschiedliche Serviceabonnenten erleichtert das Hosting und die Ausführung von Schadcode und damit die Kompromittierung von Anwendungen und Daten. 8. Unzureichende Sensibilisierung und Bewertung (Audits) von Sicherheitsrisiken sowie unsichere Wahrnehmung und Reaktionsfähigkeit auf sicherheitskritische Ereignisse 9. Technologische Bedrohungen: durch Technologien oder Anwendungen, Information disclosure die für eine strikte Isolierung in Mandanten-fähigen Umgebungen ungeeignet sind. Nur eine Anwendungsschwachstelle oder falsche Konfigurati- Elevation of privilege on reicht aus, um die gesamte Dienstleistung zu gefährden Cloud Computing Schwachstellen In ihrem Bericht weist die Cloud Security Alliance ausdrücklich darauf hin, dass für ein erfolgreiches Risikomanagement ein Verständnis der Art der Bedrohungen, möglicher Ursachen oder Angriffspunkte unabdingbar ist. Eine wichtige Grundlage hierfür ist die Wahrnehmung und angemessene Berücksichtigung bekann ter Schwachstellen und möglicher Sicherheitslücken im operativen Cloud Computing Modell. Dazu gehören: Organisatorische Schwachstellen 1. Informationssicherheit-Management: Ein fehlendes oder unzureichendes Informationssicherheit-Management fußt in der Regel auf einer unzulänglichen Bewertung organisatorischer und technischer Risiken und führt zwangsläufig zu einem unzureichenden Risikomanagement sowie fehlenden oder unzureichenden Sicherheitsrichtlinien und einer angemessenen Kontrolle ihrer Umsetzung. 2. Sicherheitsrichtlinien: Fehlende oder unzureichende Sicherheitsrichtlinien sowie die ungenügende Kontrolle ihrer Umsetzung begünstigen die fahrlässige oder beabsichtigte Umgehung von Sicherheitsmaßnahmen, den fahrlässigen oder böswilligen Umgang mit sicherheitsrelevanten Informationen. 53

54 Teil 2: Bedrohungs- und Risikoanalyse 3. Trennung von Zuständigkeiten: Fehlende oder ungenügende Trennung von Zuständigkeiten (least privilege) erleichtern die fahrlässige oder auch böswillige Eskalation von Zugriffsrechten. 4. Konfigurations- und Änderungsmanagement: Fehlende oder unzureichende Test- und Freigabeverfahren für Konfigurations-, Software- und Hardwareänderungen, Updates und Patches, begünstigen das Eintreten von Fehlfunktionen sowie externe Angriffe durch nicht entdeckte oder noch nicht behobene Schwachstellen und Abhängigkeiten. 5. Management kryptografischer Infrastrukturen: Sicheres Cloud Computing erfordert ein sicheres Management kryptografischen Materials zur Verschlüsselung von Kommunikationskanälen und gespeicherter Daten, zur zuverlässigen Authentisierung von Serviceprovidern und Servicenutzern oder (geographisch) verteilten physischen Ressourcen. Das Management und die zuverlässige Replikation kryptographischer Infrastrukturen, bspw. von Hardware-Sicherheits-Modulen (HSM) in verteilten Umgebungen ist eine besondere Herausforderung und demzufolge auch mit einer Reihe besonderer Risiken behaftet. 6. Schulungsmaßnahmen: Fehlende oder ungenügende Schulungen von Mitarbeitern begünstigen die fahrlässige Administration und Konfiguration der Cloud Plattform und führen ggf. zu unangemessenen oder unzureichenden Reaktionen auf sicherheitsrelevante Ereignisse. 7. Sicherheitsüberprüfung: Fehlende oder unzureichende regelmäßige Sicherheitsüberprüfungen erleichtern Angriffe durch böswillige Insider. 8. Zutrittskontrolle: Fehlende oder unzureichende Zutrittskontrollen zu sicherheitsrelevanten Betriebsräumen erleichtern den Diebstahl oder die Beschädigung von Geräten und Infrastrukturen sowie den nicht autorisierten Zugriff auf Medien. 9. Planung von Ressourcen: Eine ungenügende oder fehlerhafte Planung der Ressourcennutzung kann zu einer unerwarteten Erschöpfung virtueller und physischer Ressourcen und damit zu einer (partiellen) Nichtverfügbarkeit der angebotenen Dienstleistung führen. 10. Backup: Eine fehlende oder unzureichende Vorsorge für beherrschbare physische Ereignisse wie Stromausfall, Feuer oder Wassereinbruch kann zu einem Totalverlust gespeicherter Daten führen. 11. Kundenmanagement: Eine fehlende oder unzureichende Identifikation und Prüfung von Serviceabonnenten erleichtert externen Angreifern den Zugriff auf gemeinsam genutzte Ressourcen und damit gegebenenfalls den unbefugten Zugang zu Informationen. 12. Kundenmanagement: Nicht aufgelöste Konflikte zwischen Sicherheitsanforderungen von Serviceabonnenten und der verfügbaren Cloud Umgebung können zu einem erhöhten Sicherheitsrisiko für die Daten des Serviceabonnenten führen. 13. Management von Sub-Dienstleistern: Unzureichende oder fehlende Überwachung zugesicherter Leistungen durch Subdienstleister können die Verfügbarkeit des Services gefährden. 14. Mangelnde Transparenz: Mangelnde Transparenz über die Spiegelung von Daten oder die Inanspruchnahme von Rechenleistung an verteilten Standorten unterschiedlicher Rechtshoheit kann für den Serviceabonnenten zu einer fahrlässigen Verletzung rechtlicher Regelungen führen und in der Folge zivil- oder strafrechtliche Konsequenzen nach sich ziehen Technische Schwachstellen und Sicherheitslücken 1. IAA: Unsichere Identifikations-, Authentifikations- und Autorisierungsmechanismen erleichtern den nicht autorisierten Zugriff auf Daten und Ressourcen, die Eskalation von Zugriffsrechten, die Verschleierung des Missbrauchs von Ressourcen und behindern die Entdeckung sicherheitsrelevanter Ereignisse. 2. Unsichere Managementinterfaces: Die unsichere oder unzureichende Überwachung von Managementschnittstellen begünstigt die Eskalation von Zugriffsrechten, die fahrlässige oder auch 54

55 Bedrohungs- und Risikoanalyse Teil 2: böswillige Manipulation von Konfigurationsdaten, den fahrlässigen oder auch böswilligen Missbrauch von virtuellen oder physischen Ressourcen. 3. Unsichere Kommunikationskanäle: Die ungenügende kryptographische Sicherung von Kommunikationsendpunkten, -kanälen und -protokollen erleichtert das Abhören und die Übernahme von Kommunikationssitzungen. Begünstigt wird ein solcher Angriff durch unsichere Authentifikationsmechanismen oder die Akzeptanz selbst-signierter Software-Zertifikate. 4. Unzureichende Datenverschlüsselung: Fehlende oder unzureichende Verschlüsselung bewegter und gespeicherter Daten erleichtert die Aufdeckung und den Missbrauch von Informationen. 5. Unsichere Ressourcentrennung: Die unsichere Trennung (Segregation) von Ressourcen und Anwendungen erleichtert den nicht autorisierten Zugriff auf Information sowie den Missbrauch von Ressourcen. 6. Unsicheres Kryptographisches Schlüsselmaterial: Die Erzeugung und der Einsatz von Verschlüsselungsmaterial ungenügender Entropie erleichtern die Aufdeckung verschlüsselter Informationen. 7. Ressourcenerschöpfung: Fehlerhafte Ressourcenallokationsalgorithmen und -prozeduren können eine unerwartete Ressourcenerschöpfung zur Folge haben. 8. SIEM: Das Fehlen oder eine unzureichende Aggregation und Korrelation von Systemaktivitäten in einem zentralen Informationssicherheitsmonitor (SIEM) behindern die rechtzeitige Entdeckung und Abwehr des Missbrauchs von Ressourcen oder externer Angriffe. 9. Unzureichende Forensische Fähigkeiten: Unzureichende forensische Mittel und Fähigkeiten behindern die Entdeckung und Abwehr externer Angriffe. 10. Unzureichende Schwachstellentests: Unzureichende oder unregelmäßige Schwachstellentests erhöhen die Gefahr der Ausnutzung von Schwachstellen der Konfiguration und Topologie der Cloud Plattform. 11. Unsicheres Orchestration Management: Ein unsicheres Resource Orchestration Management oder eine Kompromittierung der Resource Orchestration Management Schnittstelle erhöht die Gefahr eines unsicheren oder unzuverlässigen Zusammenspiels der in die Dienstleistung involvierten Services und des Missbrauchs der involvierten Ressourcen. 12. Unsichere Konfiguration: Eine unsichere Konfiguration durch die fehlerhafte Bedienung oder ungenügende Überwachung der Nutzung von Management Schnittstellen kann externe Angriffe erleichtern oder Fehlfunktionen und den Ausfall beteiligter Komponenten auslösen. 13. Unsichere Hypervisoren: Die erfolgreiche Ausnutzung von Schwachstellen in Hypervisoren bedeutet einen erfolgreichen Angriff auf sämtliche virtuellen Maschinen, die unter ihrer Kontrolle laufen. 14. Unsichere Migration: Die unsichere Migration oder Replikation virtueller Maschinen erleichtert die feindliche Übernahme virtueller Maschinen. 15. Fehlende Standards: Fehlende oder unzureichende Standards können ebenso wie der fehlende oder unzureichende Einsatz von Standardtechnologien und Standardlösungen Inkompatibilitäten, neue und unentdeckte Schwachstellen sowie ein unerwünschtes lock-in zu einem Provider zur Folge haben. 16. Unsicherer Einsatz von HIDS: Der unzureichende oder unsichere Einsatz (die unsichere Konfiguration) von Host-based Intrusion Detection Systemen behindert die Entdeckung und Abwehr lokaler Angriffe. 17. Unsicherer Einsatz von NIDS: Der unzureichende oder unsichere Einsatz (die unsichere Konfiguration) von Netzwerk Intrusion Detection Systemen verhindert die sichere Überwachung des Netzverkehrs mit der Cloud Plattform bzw. verteilt eingesetzten Komponenten. 18. Unzureichende Härtung: Die unzureichende oder unsichere Härtung von Betriebssystemen erleichtert lokale bzw. netz-basierte Angriffe. 19. Unzureichende Redundanz: Eine ungenügende redundante Auslegung virtueller und physischer Ressourcen kann zu einer unerwarteten Erschöpfung von Ressourcen oder der Nicht-Verfügbarkeit des 55

56 Teil 2: Bedrohungs- und Risikoanalyse Service im Falle des Eintritts unerwarteter physischer Ereignisse (wie Stromausfall, Brand, oder Wassereinbruch) 20. Unzureichende Wartung: Unregelmäßige Wartungsmaßnahmen, wie das unregelmäßige Einspielen von Sicherheitsupdates oder -patches erleichtert die Ausnutzung neuer Softwareschnittstellen durch externe Angreifer. 2.3 Bedrohungs- und Risikoanalyse für ein Cloud Archiv Für ein Cloud-Archiv lassen sich eine Reihe unterschiedlicher Gefährdungen erkennen. Dazu zählen elementare Ereignisse ebenso wie technisches Versagen, die unzureichende oder unsichere Mandantenfähig keit der eingesetzten Speichersysteme sowie Fehlverhalten und vorsätzliche Angriffe begünstigt durch unsichere Rollen- und Rechtekonzepte. Entgegen der öffentlichen Wahrnehmung sind dabei interne Gefährdungen (Fehlverhalten oder vorsätzliche Handlungen) mindestens ebenso wahrscheinlich, wie folgenreich. Für ein Cloud-Archiv ist deshalb gerade auch der Schutz gegenüber internen Gefährdungen von nicht zu unter schätzender Bedeutung. Dabei geht es um Schutzmaßnahmen, die sowohl auf der physischen wie auch auf der logischen Ebene wirken. Zu den logischen Schutzmaßnahmen gehören vor allem die strikte Durchset zung von Zugriffsrechten und adäquaten Zugriffskontrollen auf Datenobjekte, Server und Datenträger auf der Grundlage sicherer Authentifikationsprozesse und Verschlüsselung der Speichermedien (siehe auch Abbildung 8). Abbildung 8: Sicherheitsthemen im Kontext virtueller Datenspeicher Neben internen Angreifern (böswilliges oder auch fahrlässiges Verhalten des Providers und möglicher Sub-Provider) sind es vor allem die Schnittstellen in der Kommunikation mit der Cloud die Angriffsflächen bieten. 56

57 Bedrohungs- und Risikoanalyse Teil 2: Ein besonderes Gewicht im Kontext eines virtuellen elektronischen Archivs erhält die sichere Trennung der Mandanten auf dem Resource Control und Orchestration Layer sowie dem Resource Abstraction und Vir tualization Layer des Cloud Stacks. In Abhängigkeit von der Schutzbedürftigkeit der gespeicherten Daten muss spätestens hier die Frage beantwortet werden, ob eine Trennung der Netzstrukturen unterschiedlicher Mandanten über virtuelle SANs oder LANs sowie separate logische Einheiten (LUNs) ausreichend ist. Um das Eindringen eines Angreifers in das Netz eines anderen Mandanten zuverlässig zu verhindern, sollte zumin dest eine Kombination aus Soft- und Hardwarezoning für den Zugriff auf physische Ressourcen genutzt oder gegebenenfalls auch separate physische und logische Netzwerke, Server und Speichersysteme einge richtet werden. Der Schutz archivierter Daten in einer Cloud Umgebung erfordert die Implementierung mehrfacher und differenzierter Schutzzonen, vor allem für Kommunikationsstrecken und -endpunkte, aber auch für den Zutritt und den Zugang zu Archivsystemen und Datenträgern. Eine weitere Herausforderung sind unaufgelöste Konflikte zwischen gesetzlichen Regelungen, denen ein Serviceabonnent hinsichtlich des Datenschutzes unterworfen ist und den durch den CSP tatsächlich vorgesehenen Sicherheitsmaßnahmen. Ein Thema, das insbesondere im Zusammenhang mit den geographischen Standorten dynamisch allozierter physischer Speicherressourcen von Bedeutung ist. Ein wesentlicher Aspekt hierbei ist die Frage, welchen rechtlichen Randbedingungen ein CSP am physischen Ort des Rechenzentrums unterworfen ist. Gesetzliche Regelungen können einen Zugriff auf Daten des Nutzers vorsehen, ohne dass der CSP den Nutzer darüber informieren muss bzw. darf. Solche gesetzlichen Regelungen gelten in der Regel unabhängig davon, was CSP und Kund vertraglich vereinbart haben. Für die in den Anlagen zu diesem Dokument ausgeführten Bedrohungs- und Risikoanalysen gemäß dem STRIDE Modell werden die in Teil 1 dieses Dokuments identifizierten Akteure, Komponenten und (externen) Kommunikationsverbindungen, die Aktivitäten sowie der IETF Cloud Stack zugrunde gelegt (siehe hierzu auch die folgende Abbildung). Abbildung 9: Übersicht über im SaaS Archive Modell involvierte Akteure und Komponenten. In der Bedrohungsanalyse nach dem STRIDE Modell werden die betrachteten Komponenten auf ihre logischen Einheiten (Layer) gemäß dem IETF Cloud Stack generalisiert. 57

58 Teil 2: Bedrohungs- und Risikoanalyse Akteure Enduser Service Subscriber Auf der Seite der Serviceabonnenten (subscriber) sind wenigstens zwei Gruppen von Akteuren direkt in die Nutzung des als SaaS bereitgestellten (virtuellen) Archivs involviert. Da sind zunächst die Endnutzer des Abonnenten, die den Service für die Speicherung von Unternehmensdaten nutzen. Sie greifen über das Access & Delivery Layer auf die im Cloud Service Layer bereitgestellte Archivanwendung zu. Für diesen Zugriff müssen sie sich im Access & Delivery Layer authentisieren (Login) und können abhängig von der für sie im Access & Delivery Layer hinterlegten Autorisierung auf die gespeicherten Daten zugreifen. Hieraus folgt unmittelbar: das Access & Delivery Layer muss eine zuverlässige Authentisierung und Trennung von Mandanten (unterschiedlichen Serviceabonnenten) durchsetzen, um bspw. ein Spoofing, d. h. die Vor täuschung falscher Identitäten, mit dem Ziel einer Eskalation von Zugriffsrechten oder einer Datenmanipu lation, zu unterbinden. Authentisierungs- und Autoriserungsdaten sind deshalb in besonderem Maße vor unbefugten Zugriffen oder auch Diebstahl zu schützen. Da der Zugriff in der Regel über das Internet erfolgt (in Abbildung 9 als ComPath1 und ComPath2 veranschaulicht) müssen die Endpunkte der Kommunikation zwischen Cloud Service Provider und Cloud Abonnenten ausreichend physisch (Betrieb in einer gesicherten und überwachten Umgebung), organisatorisch (Zutritts- und Zugangsberechtigungen) wie auch logisch (kryptographische Sicherung der Kommunikationswege und -endpunkte) geschützt werden IT-Administrator Subscriber Der IT-Adminstrator des Serviceabonnenten erhält ebenfalls über das Access & Delivery Layer (ComPath 2 in Abbildung 9) und der für ihn hinterlegten Authentisierungsdaten Zugriff auf die Archivanwendung, um Nutzerkonten inklusive der benötigten Berechtigungen anzulegen, zu verändern oder auch zu löschen. Über ein logisch im Access & Delivery Layer bereitgestelltes Management Interface erhält er zudem Zugriff auf die Cloud Mangement Plane, um unterstützt durch ein Self-Service Portal - nutzerspezifische Konfigurationen der Anwendung sowie die Allokation zusätzlicher Ressourcen (bspw. Rechenleistung oder Speicher) vornehmen zu können. Fahrlässiges oder böswilliges Verhalten eines IT-Administrators auf der Seite des Subscribers können sowohl zu einer unerwarteten Erschöpfung erforderlicher Ressourcen (Denial of Service) oder zu einer unbefugten Kenntnisnahme (Information Disclosure) und Manipulation von Kundendaten oder Nutzerkonten (Tam pering) führen IT-Administrator Provider Relevante Akteure auf der Seite des Providers sind vor allem IT-Administratoren, die - vornehmlich über die Cloud Management Plane - die Administration und Überwachung der für die Erbringung der Dienstleistung erforderlichen virtuellen und physischen Cloud Services und Komponenten im Access & Delivery Layer, im Cloud Service Layer, im Composition & Orchestration Layer, im Resource Abstraction & Virtualization Layer sowie im Physical Resource Layer auf der Grundlage von Konfigurationsdaten und Einsatzrichtlinien steuern. Die Cloud Management Plane stellt administrative Funktionen für die Konfiguration und das Aufsetzen von Cloud Services, die Bereitstellung und Entlastung von IT-Resourcen, die Überwachung (Monitoring) des Cloud Service Status, der Nutzung und Performanz, das Management von Nutzerkonten, Sicherheitsnachweisen, Authentifizierungs- und Autorisierungsdaten, 58

59 Bedrohungs- und Risikoanalyse Teil 2: die Überwachung interner und externer Zugriffe auf bereitgestellte IT-Resourcen, die Planung und Überprüfung der Bereitstellung von IT-Ressourcen sowie die Steuerung und Überwachung der Bereitstellung technischer Ressourcen (Netze, Rechenleistung oder Speicherkapazitäten) durch Dritte bereit. Fahrlässiges oder auch böswilliges Verhalten haben an dieser Stelle unmittelbare Auswirkungen auf die Vertraulichkeit und Integrität von Daten sowie die Verfügbarkeit des Archivsystems. IT-Administratoren des Cloud Service Providers sollen daher regelmäßig einer Sicherheitsüberprüfung unterzogen werden und ausreichend geschult sein. Das gilt insbesondere vor dem Hintergrund, dass die Cloud Management Plane auch Überwachungs- und Alarmfunktionen hinsichtlich des operativen Zustands der Cloud Umgebung, des Zugriffs und des Auftretens sicherheitsrelevanter Ereignisse steuert. Eine Umgehung oder auch Kompromittierung sicherheitsrelevanter Funktionen muss in Ansehung erwartbarer Bedrohungen ausgeschlossen werden können Sub-Provider Relevante Akteure auf der Seite des Sub-Providers sind vor allem IT-Administratoren, die ggf. über die Cloud Management Plane die Administration und Überwachung der für die Erbringung des Dienstleistung erforderlichen Sub-Services im Access & Delivery Layer, im Cloud Service Layer, im Composition & Orchestration Layer, im Resource Abstraction & Virtualization Layer sowie im Physical Resource Layer auf der Grundlage von Konfigurationsdaten und Einsatzrichtlinien steuern. Fahrlässiges oder auch böswilliges Verhalten kann an dieser Stelle unter Umständen die Verfügbarkeit der Dienstleistung gefährden Komponenten Access und Delivery Layer Das Access and Delivery Layer auf der Seite des Serviceproviders stellt Funktionen und allgemeine Infrastrukturkomponenten bereit, die dem Serviceabonnenten den Zugriff und die Nutzung des Service ermögli chen. Dazu gehören sowohl Nutzerportale wie auch Servicegateways zur Steuerung und Kontrolle der Zugriffe. So genannte Inter-Cloud Funktionen stellen Infrastrukturen und Komponenten bereit, um verteilte Ressourcen oder auch die Kommunikation mit Cloud Service Drittanbietern zu ermöglichen und zu steuern. Da die Nutzung überwiegend über das Internet erfolgt, umfasst diese Schicht im Allgemeinen auch Netz werkkomponenten, die in der Regel durch Netzprovider als beteiligte Dritte zur Verfügung gestellt werden. Ein erfolgreiches Spoofing im Access und Delivery Layer ermöglicht den Zugriff auf Kontodaten und damit auch auf archivierte Unternehmensdaten, es erleichtert darüber hinaus gegebenenfalls weitergehende und zudem verschleierte Angriffe, wie die Manipulation oder Fälschung von Nutzerkonten, oder gar die Umleitung von SaaS Endnutzern auf nicht legitimierte Webseiten Cloud Service Layer Das Cloud Service Layer - als unmittelbare Laufzeitumgebung der Archivanwendung - steuert den Bedarf an funktionalen virtuellen und physischen Ressourcen, die für die Ausführung der Archivanwendung benötigt werden. Das heißt, das CSL kontrolliert neben dem Ressourcentyp (CPU, Arbeitsspeicher, Festplattenspeicher usw.) die Leistungsfähigkeit, den Umfang sowie auch die Art und Weise der Bereitstellung der benötigten Ressourcen. Damit betrifft eine Gefährdung, bspw. durch Information Disclosure im Cloud Service Layer, nicht nur Konfigurations- und Prozessdaten der Archivanwendung, sondern auch die in der Anwendung verarbeiteten und über Schnittstellen kommunizierten Unternehmensdaten. Vor dem Hintergrund, dass ein erfolgreiches Information Disclosure im Cloud Service Layer auch durch eine unzureichende oder unsichere 59

60 Teil 2: Bedrohungs- und Risikoanalyse Trennung von Mandanten ermöglicht oder auch erleichtert werden kann, muss das Cloud Service Layer Sicherheitsfunktionen bereithalten, die vor allem bei gemeinsam genutzten Ressourcen - eine strikte Segregation von Mandanten-bezogenen Anwendungen und Daten gewährleisten Cloud Management Plane Die Cloud Management Plane stellt Funktionen für die Administration und Überwachung des Cloud Umgebung bereit. Dazu gehören vor allem: die automatische Einbindung (der Einsatz) verschiedener Cloud Komponenten auf der Grundlage von Konfigurationsdaten und Einsatzrichtlinien, die Registrierung und Verwaltung von Services, Überwachungs- und Alarmfunktionen hinsichtlich des operativen Zustands der Cloud Umgebung, d. h. der Nutzung des Cloud Service, der Einhaltung der vereinbarten Leistungsparameter sowie des Zugriffs und des Auftretens sicherheitsrelevanter Ereignisse. Eine unzulässige oder auch nur unbemerkte Erweiterung von Berechtigungen (Elevation of Privilege) in der Cloud Management Plane gestattet es, Sicherheitsdienste zu konfigurieren. Dadurch werden weitere Attacken, wie bspw. Tampering, Information Disclosure oder Denial of Service, ermöglicht oder erleichtert Resource Control Layer Das Resource Control (Composition & Orchestration) Layer orchestriert die Bindung der über das Abstraction & Virtualization Layer virtualisierten physischen Ressourcen an mandantenbezogene Anwendungen, Konfigurationen und Daten. Die Orchestrierung beginnt mit der Anforderung eines Services, einer Anwendung oder einer Funktion im Access & Delivery Layer und endet mit der Koordination verschiedener IT-Schichten und Komponenten, die direkt oder auch indirekt in die vom Endnutzer angeforderte Leistung involviert sind. Aus sicherheitstechnischer Perspektive ist die Orchestrierung ein prozessualer Verbund von Komponenten, die in einer sicheren und zuverlässigen Art und Weise zusammenarbeiten müssen. Zu den für die Orche strierung zu beachtenden Sicherheitsaspekten gehören (siehe auch Abbildung 10): Abbildung 10: Sicherheitsaspekte im Resource Control (Composition & Orchestration) Layer 60

61 Bedrohungs- und Risikoanalyse Teil 2: sichere Serviceübergabeschnittstellen, d. h. geeignete Sicherheitsmaßnahmen, mit denen der Ende-zu-Ende Lebenszyklus des Services überwacht werden kann, sichere Ressourcenbereitstellung, d. h. ein Sicherheitsdesign aus operativer Perspektive der prozessual orchestrierten Bindung von Ressourcen sowie ein sicheres Management der Orchestrierung, denn die Managementschnittstellen für die Orchestrierung bestimmen maßgeblich die Verfügbarkeit und Sicherheit der gesamten SaaS Cloud Umgebung und müssen daher in besonderer Weise geschützt werden, ein zuverlässiges Sicherheitsmonitoring der Orchestrierung zur Laufzeit, so dass verdächtiges, oder auch nur außergewöhnliches Verhalten im Orchestrierungsprozess nicht unentdeckt bleibt. Das Resource Control Layer koordiniert und verbindet je verschiedene Schichten von Anwendungen, Netzen, virtuellen Maschinen und Hypervisoren, Betriebssystemen und Speicherbereichen und ist deshalb aus si cherheitstechnischem Blickwinkel ein besonders kritischer Bereich und ein lukratives Ziel, sowohl für Information Disclosure wie auch Denial of Service Attacken. Von Information Disclosure bedroht sind im Resource Control Layer vornehmlich Konfigurationsdaten (von FC Switches oder HBAs), weil durch sie die Segmentierung der (virtuellen) Ressourcen maßgeblich bestimmt und über ihre Kenntnisnahme ein direkter Zugriff auf Kundendaten möglich wird. Im Kontext vernetzter Datenspeicher bspw. genügt der Snapshot eines SAN um Kenntnis einer LUN oder LUN-Gruppe und damit der Adresse gespeicherter Daten zu erhalten Kommunikation Subscriber Cloud Service Provider Die Sicherheit der Netzkommunikation ist die Grundlage für die Sicherheit der Cloud insgesamt. Das Access & Delivery Layer muss deshalb imstande sein, eine vertrauenswürdige Kommunikationsverbindung mit dem Serviceabonnenten aufzubauen, um bspw. die Übernahme von Kommunikationsverbindungen (session riding / hijacking) zu verhindern. Das schließt die Prüfung der Gültigkeit und Integrität des Datenaustausches zwischen dem Cloud Service Provider und dem Cloud Service Abonnenten ebenso ein, wie die Bereitstel lung von Firewalls, Intrusion Detection Systemen (IDS) und Intrusion Prevention Systemen (IPS) auf Netzwerkebene, um die bei der Kommunikation über etablierte Netzwerkverbindungen ggf. auftretenden Bedro hungen zuverlässig zu erkennen und abwehren zu können Vorgehen Der Aufbau der als Anlagen zu diesem Dokument beigefügten Bedrohungs- und Risiko- Steckbriefe folgt dem nachfolgend dargestellten Muster: Tabelle 5: Muster der Bedrohungs- und Risikosteckbriefe Komponente Name und Kurzbeschreibung der Komponente für die Bedrohungs- und Risikoanalyse gemäß STRIDE Klassifikation ausgeführt wird Bedrohung Bedrohung gemäß STRIDE Klassifikation Beschreibung der Bedrohung An dieser Stelle erfolgt eine kurze Beschreibung der Bedrohung vor allem auch hinsichtlich möglicher, nach STRIDE klassifizierter Folgebedrohungen wie bspw. Information Disclosure oder Tampering Beschreibung besonderer Bedrohungsszenarien An dieser Stelle werden für die betroffene Komponente erkennbare Einzelbedrohungsszenarien beschrieben.. 61

62 Teil 2: Bedrohungs- und Risikoanalyse Eintrittswahrscheinlichkeit Eine qualitative Bewertung der Eintrittswahrscheinlichkeit Schadenswirkung Eine qualitative Bewertung der Schadensauswirkungen Risikobewertung Eine qualitative Bewertung des Risikos Prozesse, die von der Bedrohung direkt betroffen sind. Hier werden die im Teil 1 dieses Dokuments beschriebenen Prozesse benannt, die von einer erfolgreichen Verwirklichung der Bedrohung direkt betroffen wären. Prozesse, bei welchen die Bedrohungen am ehesten zu erwarten sind. Hier werden die im Teil 1 dieses Dokuments beschriebenen Prozesse benannt, in denen eine erfolgreiche Verwirklichung der Bedrohung am ehesten erwartet werden kann. Referenzen auf die Sicherheitsanforderungen gemäß BSI Eckpunktepapier (siehe dazu Teil 1 dieses Dokuments) Restrisiken An dieser Stelle werden Restrisiken benannt, die ggf. trotz eingeleiteter Schutzmaßnahmen zur Abwehr der Bedrohung, beachtet und bewertet werden sollten. Bereiche, die noch näher betrachtet werden sollten. Hier werden Themenfelder benannt, die ggf. Gegenstand weitergehender Analysen werden sollten. Die Risikobewertung folgt im Wesentlichen dem BSI-Standard Da eine aussagekräftige Abschätzung der Schadensauswirkungen bei Eintritt eines Risikos mittels einer Business Impact Analyse (BIA) vor dem Hintergrund aktueller Erfahrungen kaum möglich ist, werden mögliche Schadenswirkungen mittels qualitativer Begriffe niedrig, normal, hoch, sehr hoch bewertet. Das gilt auch für Beschreibung der Eintrittswahrscheinlichkeit mit den Begriffen häufig, wahrscheinlich, gelegentlich, vorstellbar, unwahrscheinlich und unvorstellbar. Die Kombination von Schadenswirkungen und Eintrittswahrscheinlichkeiten ergibt ein qualitatives Maß für die Abschätzung des Risikoniveaus, wie beispielsweise in dem folgenden Risikographen in Tabelle 6 dargestellt. Dabei kann jedoch die letztendliche Bewertung eines Risikos durchaus von Zuordnung des Graphen abweichen, wenn bspw. die Bewertung der möglichen Schadenswirkung aus der Perspektive des Servicea bonnenten zu einer anderen Einschätzung zwingt. Tabelle 6: ALARP Graph29 AUSWIRKUNGEN WAHRSCHEINLICHKEIT NIEDRIG NORMAL HOCH SEHR HOCH häufig ALARP Inakzeptabel Inakzeptabel Inakzeptabel wahrscheinlich ALARP Inakzeptabel Inakzeptabel Inakzeptabel gelegentlich ALARP ALARP Inakzeptabel Inakzeptabel 29 ALARP ist ein Akronym und steht für: As Low As Reasonable Practicabel (so niedrig, wie vernünftigerweise praktikabel) Quelle: Klipper, S.: Information Security Risk Management Risikomanagement mit ISO/IEC 27001, und 3110, Vieweg & Teubner, Wiesbaden 2011, S

63 Bedrohungs- und Risikoanalyse Teil 2: AUSWIRKUNGEN vorstellbar Akzeptabel ALARP ALARP Inakzeptabel unwahrscheinlich Akzeptabel Akzeptabel ALARP ALARP unvorstellbar Akzeptabel Akzeptabel Akzeptabel Akzeptabel Den Bedrohungen werden die in Teil 1, Kapitel 5 dieses Dokuments identifizierten Sicherheitsanforderungen zugeordnet. Im Anschluss werden Restrisiken benannt, die akzeptiert werden können oder müssen, auf den Serviceabonnenten verlagert werden können oder auch gegebenenfalls unter anderen Umständen und Bedingungen zu nicht akzeptablen Risiken werden können. Abschließend erfolgt eine kurze Beschreibung von Themenfeldern, die ggf. Gegenstand weitergehender und detaillierterer Untersuchungen sein sollten. 63

64 Teil 2: Bedrohungs- und Risikoanalyse 64

65 Sicherheitsmaßnahmen für das Archiving SaaS Modell Teil 3: Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell 3.1 Einleitung In Teil 2 dieses Sicherheitsprofils wurden für ein als Software-as-a-Service in einer Cloud Computing Umgebung zur Verfügung gestelltes Archivsystem dreizehn wichtige Bedrohungen für die Schichten des IETF Cloud Stacks identifiziert, beschrieben und in Form von Steckbriefen detailliert für die nachfolgend aufgeführten Bedrohungen und Komponenten des IETF Cloud Stacks beschrieben: für das Access & Delivery Layer: Spoofing, Repudiation, Information Disclosure, für das Cloud Service Layer: Tampering und Information Disclosure für die Cloud Management Plane: Tampering, Denial of Service und Elevation of Privilege für das Cloud Resource & Orchestration Layer: Tampering, Information Disclosure, Denial of Service und Elevation of Privilege, für die Kommunikation des Serviceabonnenten mit der Access & Delivery Layer Denial of Service. Das vorliegende Dokument Teil 3 des Sicherheitsprofils für ein SaaS Archivsystem beschreibt Sicherheitsmaßnahmen organisatorischer, technischer und personeller Natur, die geeignet sind, den in Teil 2 genannten Bedrohungen entgegen zu wirken. Übergreifende Bedeutung haben dabei Maßnahmen, welche die Kommunikation mit der Cloud sowie die Verarbeitung und Speicherung von Daten in den Schichten des Cloud Stacks in besonderer Weise zu schützen. Dazu gehören: die zuverlässige Kennzeichnung (Attribuierung) von Informationen und Daten gemäß der durch den Serviceabonnenten definierten Schutzbedürftigkeit, die strikte Trennung des Zugangs und des Zugriffs auf Informationen und Daten verschiedener Mandanten die strikte Trennung des Zugangs und des Zugriffs auf Informationen und Daten durch die Endnutzer eines gemäß dem festgelegten Schutzbedarf und den Endnutzern zugewiesenen Zugriffsrechten, 65

66 Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell sichere und nicht zu umgehende Authentifikationsprozesse zur Verhinderung einer Eskalation von Zugriffsrechten, die sichere Konfiguration der in der Bereitstellung des Service involvierten Komponenten des Cloud Stacks sowie die strikte und sichere Segmentierung virtueller und physischer Ressourcen. Jede Maßnahme wird in Anlehnung an [RFC2119] explizit als verpflichtend, empfohlen oder als optional spezifiziert und den Bedrohungsklassen nach dem STRIDE Modell zugeordnet. Verpflichtende Anforderungen (MUSS-Anforderungen), sind Anforderungen, deren Umsetzung zwingend gefordert wird. Sie sind im Text mit den Worten muss (müssen) / ist (sind) / darf (dürfen) nur / darf (dürfen) nicht, ausgezeichnet. Empfohlene Anforderungen (SOLL-Anforderungen) sollten umgesetzt werden. Sie sind im Text mit den Worten soll (sollen) / empfohlen ausgezeichnet. Optionale Anforderungen (KANN-Anforderungen) können umgesetzt werden. Sie sind im Text mit den Worten kann (können) / darf (dürfen) ausgezeichnet. STRIDE ist ein Akronym und steht für Spoofing (nachahmen, Vortäuschen einer Identität), Tampering (fälschen, manipulieren von Daten), Repudiation (Abstreiten einer Handlung), Information Disclosure (aufdecken, veröffentlichen von Informationen), Denial of Service (Dienstverweigerung) und Elevation Privilege (unzulässige Erweiterung von Rechten). STRIDE wurde 2002 von Microsoft für die Klassifizierung von Angriffsmustern entwickelt. In Teil 4 dieses Sicherheitsprofils werden die Sicherheitsmaßnahmen in einer Kreuzreferenztabelle auf die Bedrohungen abgebildet. Auf diese Weise lässt sich nachvollziehen, inwieweit durch die Sicherheitsmaßnahmen eine Abdeckung und damit auch eine erfolgreiche Abwehr der aufgezeigten Bedrohungen möglich wird. 66

67 Sicherheitsmaßnahmen für das Archiving SaaS Modell Teil 3: 3.2 Sicherheitsmaßnahmen Organisatorische Sicherheitsmaßnahmen Index Titel und Beschreibung M1.01 Informations- und Sicherheitsmanagement M Der Cloud Service Provider muss über formale und dokumentierte Sicherheitsrichtlinien verfügen. Die Sicherheitsrichtlinien müssen Ziele, Geltungsbereiche, Rollen und Verantwortlichkeiten, die Koordination unterschiedlicher Unternehmensbereiche, Sicherheitsarchitekturen und -maßnahmen zum Schutz von Daten, IT-Systemen und IT-Infrastrukturen, sowie Maßnahmen zur Einhaltung rechtlicher Anforderungen (Compliance) beschreiben. Wesentliche Bestandteile der Sicherheitsrichtlinien sind ein zuverlässiges Storage Security Konzept sowie ein gegebenenfalls erforderliches Verschlüsselungskonzept (siehe auch M1.03-3(2). M Vor dem Hintergrund der in Teil 2 dieses Sicherheitsprofils beschriebenen Bedrohungsszenarien sind dabei insbesondere folgende (Detail-) Aspekte zu berücksichtigen: M1.01-2(1) IAM, Zutritts-, Zugangs- und Zugriffskontrolle: In Zusammenarbeit bzw. nach den Vorgaben des Serviceabonnenten muss ein Konzept zur Kontrolle und zur Steuerung von Zugriffsrechten (Identity & Access Management), auf die Funktionen des Cloud Self-Service Portals und die Kundendaten des Serviceabonnenten (siehe M1.03-3(1)) definiert und umgesetzt werden. STRIDE S T R I D E S T R I D E Zugangs- und Zugriffsberechtigungen sind nicht nur auf der Basis der Identität der Akteure festzulegen, sondern auch auf der Grundlage zusätzlicher Regeln und Eigenschaften der Komponenten und Funktionen des Archivsystems sowie der Zugriffsobjekte (bspw. auf der Grundlage der Klassifizierung/Einstufung gem. der Schutzbedarfsfeststellung des Serviceabonnenten). Das Identity & Access Management (IAM) Konzept soll eine nachvollziehbare Kombination aus zwingend erforderlichen und systemtechnisch erzwungenen Zugangsund Zugriffskontrollen (Mandatory Access Controls) und benutzerbestimmbaren / benutzerbestimmten Zugangs- und Zugriffskontrollen (Discretionary Access Controls) abbilden und durchsetzen. Zusätzlich müssen verbindliche Regelungen zur regelmäßigen Überprüfung der Notwendigkeit und Zulässigkeit bzgl. der Aufrechterhaltung erteilter Berechtigungen festgelegt werden. M1.01-2(2) Sicherheitsüberprüfungen von Personal: Siehe M3.01 M S T R I D E Auf der Grundlage dieser Sicherheitsrichtlinien sind durch den der Cloud Service Provider dokumentierte Prozesse zu etablieren, welche die Aktualität und Umsetzung 67

68 Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell der Sicherheitsrichtlinien durchsetzen, kontrollieren und ihre Wirksamkeit regelmäßig überprüfen und nachvollziehbar dokumentieren. M1.02 Risiko- und Incidentmanagement M Der Cloud Service Provider muss über formale und dokumentierte Richtlinien zum Risikomanagement verfügen. Die Richtlinien müssen Ziele, Geltungsbereiche, Rollen und Verantwortlichkeiten sowie Festlegungen zur regelmäßigen Analyse und Bewertung möglicher Bedrohungen von Informationen und Informationssystemen und zum Umgang mit sicherheitsrelevanten Ereignissen umfassen. S T R I D E M Auf der Grundlage dieser Richtlinien sind durch den Cloud Service Provider dokumentierte Prozesse zu etablieren, die eine angemessene Reaktion auf sicherheitsrelevante Ereignisse auslösen sowie die in den Richtlinien beschriebenen Maßnahmen zur Abwehr von Sicherheitsbedrohungen und Dokumentation durchsetzen. S T R I D E M Der Cloud Service Provider muss dokumentierte Prozesse etablieren, welche die Umsetzung der Richtlinien durchsetzen und kontrollieren sowie ihre Wirksamkeit und Aktualität regelmäßig überprüfen und nachvollziehbar dokumentieren. Dazu gehört auch die regelmäßige Informationsbeschaffung über bekannte und neue Sicherheitslücken oder Schwachstellen, sowie dagegen anwendbare Maßnahmen, unter Nutzung unterschiedlichster, unabhängiger Quellen (bspw. Hersteller, CERT's etc.). S T R I D E M Die Zuverlässigkeit und Angemessenheit der in den Richtlinien beschriebenen Abläufe und Maßnahmen soll durch regelmäßige Assessments vor dem Hintergrund der aktuellen Bedrohungslage überprüft werden. S T R I D E M1.03 Schutz von Informationen M Aufbauend auf M1.01 muss der Cloud Service Provider über formale und dokumentierte Richtlinien zum Umgang mit und zum Schutz von sicherheitsrelevanten Informationen bei der Verarbeitung, dem Transport, der Migration (einschließlich der involvierten virtuellen und physischen Ressourcen), der Speicherung und der Löschung von Daten verfügen. Dazu gehören Kundendaten (hier Archivdaten), Konfigurations- und Prozessdaten der involvierten IT-Infrastruktur wie auch Protokolldaten über Aktivitäten und sicherheitsrelevante Ereignisse. M Die Richtlinien müssen Ziele, Geltungsbereiche, einschließlich stufenweiser und von einander getrennter Architekturen, logischer Zonen und Bereiche (bspw. mittels segmentierter SAN und separater Administratoren-Netze), Rollen und Verantwortlichkeiten, die Einstufung des Schutzbedarfes und Festlegungen für eine in Systematik und Durchsetzung wirksame Zugriffskontrollstrategie, mit der ein unbefugter Zutritt und Zugang zu, sowie Zugriff auf oder der Verlust von Informationen nicht unentdeckt bleibt und zuverlässig verhindert werden kann, umfassen. M Vor dem Hintergrund der in Teil 2 dieses Sicherheitsprofils beschriebenen 68

69 Sicherheitsmaßnahmen für das Archiving SaaS Modell Teil 3: Bedrohungsszenarien sind dabei insbesondere folgende (Detail-) Aspekte zu berücksichtigen: M1.03-3(1) Klassifizierung/Einstufung und Kennzeichnung von Informationen/Daten: Der Cloud Service Provider muss eine eindeutige Klassifizierung/Einstufung und unverwechselbare digitale Kennzeichnung von Informationen und/oder Daten des jeweiligen Serviceabonnenten unterstützen und umsetzen. Dabei sind sowohl die kritischen Kundendaten auf den Datenhaltungsschichten und -systemen zu berücksichtigen, als auch die Konfigurationsdaten der involvierten Komponenten. Die Einstufung des Schutzbedarfes von Kundendaten muss in Abstimmung mit den Serviceabonnenten erfolgen. S T R I D E Die Sicherheitsziele und -maßnahmen des CSP dürfen nicht zu einer Minderung von Schutzbedarfsfeststellungen des Serviceabonnenten oder zur Verletzung rechtlicher Anforderungen führen. Die unverwechselbare, digitale Kennzeichnung von Informationen und Daten soll Grundlage für die erforderliche Separierung von anderen Mandanten und externen Dritten sowie für die Trennung von Zugriffsberechtigungen bzgl. der (internen) Akteure des jeweiligen Dienstabonnenten sein. M1.03-3(2) Storage Security: Die wichtigen Komponenten der Infrastruktur (hier vor allem der Speicherressourcen) und die kritischen Datenbestände auf Speicher-Arrays und Bändern sind so abzusichern, dass sie gegen elementare Einflüsse, Missbrauch und Datenkorruption geschützt sind. Ein möglicher Datendiebstahl darf aufgrund einer durchgängigen und starken Storage-Verschlüsselung der archivierten Informationen keine Folgeschäden für den betroffenen Serviceabonnenten/Mandanten haben. S T R I D E Das Storage Security Konzept des Cloud Service Providers soll sich in einem selektiven und abgestuften Ansatz am Wert der zu sichernden Daten gemäß der Schutzbedarfsfeststellung des jeweiligen Dienstabonnents orientieren (siehe dazu auch M1.03-3(1)). Dieses Storage Security Konzept ist Bestandteil der IT-Sicherheitsleitlinie des CSP und entsprechend auf die Bedürfnisse eines jeden Serviceabonnenten/Mandanten anzuwenden. Das Konzept soll den Aufbau einer mehrstufigen Storage Security Architektur beim CSP ermöglichen, welche die aus dem Datenschutzbedarf abgeleiteten Sicherheitsanforderungen für Data-at-Rest und Data-in-Motion auf der Grundlage eines stringent geplanten Zonenkonzepts berücksichtigt und durchsetzt. Diese Anforderungen sollen unter Einsatz ausschließlich geeigneter Produkte (Speicherlösungen) erfolgen. Das Storage Security Konzept muss die Grundlage zur Sicherstellung und Gewährleistung der Integrität aller schützenswerten Daten sein, eine zuverlässige Mandantentrennung durchsetzen und eine regelmäßige Überprüfung der erforderlichen organisatorischen Maßnahmen und Prozesse festlegen (siehe auch M2.02-2(2). M1.03-3(3) Datensicherung, Archivierung, Backup & Recovery: Zur Sicherstellung der Verfügbarkeit von Informationen bzw. zur Vermeidung von Datenverlusten, sowie der erforderlichen Integrität, sind zuverlässige Prozesse einer regelmäßigen Datensicherung (Backup) und Wiederherstellung von Daten (Recovery) S T R I 69

70 Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell etablieren, einschließlich der Maßnahmen zur regelmäßigen Überprüfung der Wiederherstellbarkeit von Datensicherungen. D E Gesetzliche, sowie datenschutzrechtliche Maßgaben, sind hierbei ebenso zwingend zu berücksichtigen, wie der durch den Serviceabonnenten festgelegte Schutzbedarf. Vertrauliche und besonders schutzbedürftige Daten sind vor der Sicherung so zu verschlüsseln, dass diese während des gesamten, vertraglich vereinbarten Zeitraums der Archivierung entschlüsselt und verwendet werden können. Dabei ist insbesondere für den sicheren Umgang mit Archivdatenträgern eindeutig zu regeln, welche Daten wann, wie und durch welches hierzu berechtigte Personal gesichert sowie ggf. im Anschluss zu welchem Zweck und wohin transportiert sowie am Zielort wie aufbewahrt werden. Diese Tätigkeiten sind nachweisbar durchgängig und lückenlos zu dokumentieren. Maßgaben der Kennzeichnung von Information (siehe M1.03-3(1)) und der sicheren Löschung bzw. Vernichtung von Daten (siehe M1.03-3(4)) sind hierbei zwingend anzuwenden. Zusätzlich sollen diese Konzepte und Richtlinien im jeweiligen Notfallkonzept (Disaster Recovery) integriert werden. M1.03-3(4) Sichere Löschung und Vernichtung von Daten: Auf Verlangen des Serviceabonnenten oder nach Beendigung des Servicevertrages müssen sämtliche Daten des Serviceabonnenten, einschließlich der auf Backup-Systemen gespeicherten Daten, innerhalb eines vertraglich vereinbarten Zeitraums von den Speichermedien des Cloud Service Providers sicher gelöscht (durch mehrfaches Überschreiben der Daten bspw. einer LUN) werden. Die Löschung ist durch Vorlage eines Löschprotokolls zu belegen. S T R I D E Anmerkung: Falls diese Löschung lediglich darin besteht, die Referenz auf die Daten zu löschen (bspw. die konkrete LUN), sollte der CSP den Abonnenten über die (durchschnittliche) Zeitdauer informieren, innerhalb derer die auf den physischen Sektoren im Speichernetz des CSP abgelegten Daten als nicht wiederherstellbar gelten dürfen. Das dafür eingesetzte Verfahren, bspw. basierend auf dem 'National Industrial Security Program Operating Manual (NISPOM DoD M vom Februar 2006, und der Zeitraum sollten vertraglich festgehalten werden. Bei dieser Variante, die 7 Durchläufe ausführt, (DoD M ECE) werden die Daten zunächst mit den 3 Durchläufen des DoD M (E) Standards überschrieben, danach mit einem Zufallswert, anschließend erneut durch DoD M (E)). Die Löschung und Vernichtung von Daten bezieht sich auch auf Informationen bzgl. der Authentifikation und Berechtigung von Akteuren/Subjekten (siehe M1.01-2(1)). Wenn ein Mitarbeiter des CSP das Unternehmen verlässt oder der Vertrag mit Servicepartnern erlischt bzw. beendet wird, müssen Authentifikationsdaten und Berechtigungen unverzüglich gelöscht werden. Jede Löschung ist nachweisbar festzuhalten. M Der Cloud Service Provider muss dokumentierte Prozesse etablieren, die die Umsetzung dieser Richtlinien durchsetzen, kontrollieren und ihre Wirksamkeit regelmäßig überprüfen und nachvollziehbar dokumentieren. M1.04 Schutz von Informationssystemen M Aufbauend auf M1.01 muss der Cloud Service Provider über formale und dokumentierte Richtlinien für die Identifikation und Authentifikation beim Zutritt und Zugang zu, sowie den Zugriff auf Komponenten und Systeme des Service verfügen. 70

71 Sicherheitsmaßnahmen für das Archiving SaaS Modell Teil 3: M Die Richtlinien sollen Ziele, Geltungsbereiche, einschließlich der Gestaltung dementsprechender Infrastrukturen und physisch gesicherter Bereiche, die physische Redundanz von Systemen und Infrastrukturen sowie deren Überwachung (Monitoring) umfassen. Die Richtlinien müssen Rollen und Verantwortlichkeiten, die Koordination unterschiedlicher Unternehmenseinheiten sowie ein in Systematik und Durchsetzbarkeit wirksames Rollen- und Rechtekonzept beschreiben, welches einen unbefugten oder unentdeckten Zutritt und Zugang zu, sowie Zugriff auf Informationssysteme zu verhindern imstande ist. M Vor dem Hintergrund der in Teil 2 dieses Sicherheitsprofils beschriebenen Bedrohungsszenarien sind dabei insbesondere folgende (Detail-) Aspekte zu berücksichtigen: M1.04-3(1) Gesicherte Infrastruktur: Um die technischen Ressourcen (einschl. der Archivdatenträger) und Kommunikationsendpunkte vor nicht-autorisiertem Zugang, Zutritt und Zugriff schützen zu können, sind die Informationssysteme und Komponenten innerhalb einer gesicherten Umgebung operativ zu betreiben. Das kann bspw. eine durch ein Sicherheitsunternehmen unter Zuhilfenahme angemessener Sicherheitssysteme Zäune mit Sensoren und Meldegruppen sowie einer Videoüberwachung (CCTV) oder sonstige Einfriedung sein, für die mittels unterschiedlicher Mehr-Faktor Zugangskontrollsysteme (Passwort und Smart-Card, Passwort und/oder Überprüfung biometrischer Merkmale, etc.) der Zutritt nur für autorisiertes Personal ermöglicht wird. M1.04-3(2) Schutz vor Schadprogrammen: Um die Informationssysteme, einschließlich der darauf verarbeiteten bzw. gespeicherten Daten vor Schadprogrammen schützen zu können, muss der CSP vorbeugende Maßnahmen definieren sowie das Vorgehen im Fall einer Infektion mit Schadprogrammen bzw. der Feststellung von Schadprogrammen regeln. Dabei ist sicherzustellen, dass sowohl alle relevanten organisatorischen Prozesse (bspw. Datenaustausch mittels mobiler Datenträger), wie auch die technische Umsetzung (bspw. durch Bildung von Teilnetzen und die sichere Grundkonfiguration von Systemen) bzgl. des Infektionsschutzes gewährleistet werden und die Verbreitung sowie die Schadenswirkung von bereits auf den Systemen befindlichen Schadprogrammen effektiv minimiert wird (zweckmäßige Definition von Gegenmaßnahmen). S T R I D E S T R I D E Dafür sind die Planung und der Einsatz geeigneter Hardware- und Softwarekomponenten erforderlich, welche mittels eines zentralen Managementwerkzeugs verwaltet und überwacht werden können. Dieses zentrale Management soll sicherstellen, dass alle relevanten Komponenten mindestens ein Mal täglich mit aktuellen Angriffsmustern und Signaturen versorgt werden können und zugleich über eine Schnittstelle für Alarme und Meldungen zu weiteren Überwachungs- und Korrelationssystemen verfügen. Die im Rahmen des Schutzes vor Schadprogrammen definierten Richtlinien sollen darüber hinaus im Konzept bzgl. der Pflege von Informationssystemen, Patches, Updates und Upgrades berücksichtigt werden, um einerseits einen präventiven Schutz gewährleisten zu können und andererseits insbesondere im Rahmen von Gegenmaßnahmen auch auf bestehende Gefährdungen durch Schadprogramme reagieren zu können (bspw. durch das Schließen von Schwachstellen in einer 71

72 Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell Software). M1.04-3(3) Schutz vor APT (Advanced Persistent Threats): Die Cloud-Umgebung des CSP muss gegen APT-Attacken geschützt werden. Dazu müssen geeignete Network Access Control-Mechanismen (NAC) umgesetzt werden, welche sich als (mehrstufige) Schutzzonen über alle in Kommunikation miteinander befindlichen Komponenten (dazu zählen auch die Anwendungen und Schnittstellen) und Systeme erstrecken. S T R I D E Die Umsetzung sollte mittels effizienter NAC in Verbindung mit anderen Secure Remote Access-Techniken, unterstützt bspw. durch Firewalls und Hybrid IPsec/SSL VPNs, erfolgen. Anmerkung: Da APT-Attacken häufig auch durch Social Engineering ermöglicht werden, sind die Mitarbeiter des CSP regelmäßig auf die Gefahren und den Umgang mit Social Engineering hinzuweisen und zu schulen (siehe dazu auch M3.03-4). M1.04-3(4) Notfallkonzepte (Disaster Recovery): Der Cloud Service Provider muss über formale und dokumentierte Richtlinien für den Schutz von Informationssystemen für den Fall verfügen, dass unerwartete, aber technisch beherrschbare Ereignisse eintreten. Zu diesen Ereignissen zählen unter anderem der Ausfall technischer Komponenten oder Bedrohungen durch Elementarereignisse wie Feuer, Wasser oder andere Umwelteinflüsse. S T R I D E Diese Richtlinien sollten Teil eines umfassenden Notfallmanagements (Business Continuity Management) auf der Basis etablierter Standards (z.b. ISO oder BSI-Standard 100-4, ect.) sein. Die darin beschriebenen Regelungen und Maßnahmen sollten regelmäßig, auf der Basis etablierter Prozesse erprobt und auf ihre Wirksamkeit und Zulässigkeit hin überprüft werden. M1.04-3(5) Pflege von Informationssystemen, Patches, Updates und Upgrades: Die Systeme und Komponenten der Cloud-Umgebung des CSP müssen in regelmäßigen Intervallen sowie bei aktuell gegebenem Anlass mit verifizierten und zuvor erfolgreich getesteten Patches & Updates aktualisiert werden. Vor der Aktualisierung oder sonstigen Pflegemaßnahme müssen diese erfolgreich innerhalb einer separaten Test- und Referenzumgebung getestet worden sein. Dies muss der Aktualisierung in der Produktivumgebung vorangehen, um die aus der gegebenen Komplexität nicht kalkulierbaren Sachverhalte vorher feststellen und evaluieren zu können, ohne die Grundschutzwerte des operativen Systems/der operativen Umgebung zu gefährden. S T R I D E Die Aktualisierungen dürfen die Sicherheitseigenschaften und -funktionen der Systeme und Komponenten nicht korrumpieren. Zur Sicherstellung der Verfügbarkeit der Cloud Services für die Serviceabonnenten sind derartige Maßnahmen rechtzeitig vorher anzukündigen bzw. bei einem größeren Umfang (bspw. beim Upgrade von Hard- und Software) mit den betroffenen Mandanten gemeinsam abzustimmen. M Der Cloud Service Provider muss dokumentierte Prozesse etablieren, welche die Realisierung dieser Richtlinien durchsetzen, kontrollieren und ihre Wirksamkeit regelmäßig überprüfen und nachvollziehbar dokumentieren.

73 Sicherheitsmaßnahmen für das Archiving SaaS Modell Teil 3: Technische Sicherheitsmaßnahmen Index Titel und Beschreibung M2.01 Authentifizierung und Autorisierung M Die Informationssysteme des Cloud Service müssen eine M zuverlässige Replay-resistente Multifaktor-Authentisierung für Netzwerkzugriffe auf privilegierte und nicht-privilegierte Nutzerkonten eines Serviceabonnenten und eine zuverlässige Replay-resistente Multifaktor-Authentisierung für Zugriffe auf Komponenten, Systeme und Daten des Service durch Mitarbeiter des Serviceproviders sowie in die Bereitstellung des Service involvierter Dritter durchsetzen. STRIDE S T R I D E Dabei ist sicherzustellen, dass rollen- und regelbasierte Zugriffe auf Komponenten und Systeme nur in Verbindung mit einer eindeutigen, individuellen (d. h. personenoder für Dienste mittels einer systembezogenen) Authentifizierung möglich sein dürfen. Die personen- oder systembezogene Authentisierung muss der rollen- und regelbasierten Authentisierung übergeordnet sein. Eine Umgehung von Authentifizierungsmaßnahmen beim Zugriff auf Anwendungen, Komponenten und Daten darf nach dem Stand der Technik nicht möglich sein. Ein nicht autorisierter Zugriff auf und die Manipulation von Authentifizierungsinformationen muss nach Maßgabe zu erwartender Bedrohungen ausgeschlossen werden können. Anmerkung: Um darüber hinaus eine sicheren nach Mandanten und nach Akteuren getrennten Zugriff etablieren zu können, ist die Kennzeichnung (Attribuierung) von Informationen und Daten gem. der Schutzbedarfsfeststellung des Serviceabonnenten eine wesentliche Voraussetzung. Auf der Grundlage dieser Kennzeichnung kann im Anschluss an die erfolgreiche Authentifikation des jeweiligen Akteurs auch die Autorisierung für den Zugriff auf Anwendungen und Objekte zweifelsfrei festgestellt werden. M2.02 Schutz gespeicherter Daten M Die Informationssysteme des Cloud Service müssen sicherstellen, dass ein Zugriff auf Archivdaten) erst nach erfolgreicher und zweifelsfreier Identifikation und Authentifikation (sowohl bzgl. aller Akteure, als auch infrage kommender Dienste) möglich ist (siehe auch M1.01, M1.03, M1.04 und M2.01). Durch die zwingende Verknüpfung rollenund regelbasierter Zugriffe mit individuellen Authentifikationsinformationen muss eine unbemerkte Eskalation von Zugriffsrechten verhindert werden können. Um den nur für autorisierte Akteure möglichen Zugriff auf gespeicherte (archivierte) Daten noch granulärer und gemäß dem seitens der unterschiedlichen Mandanten geforderten Schutzbedarf sicherstellen zu können, sind seitens des CSP verschiedene, voneinander separierte 73

74 Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell (physische) Speicherpools einzusetzen. M Vor dem Hintergrund der in Teil 2 dieses Sicherheitsprofils beschriebenen Bedrohungsszenarien sind dabei insbesondere folgende (Detail-) Aspekte zu berücksichtigen: M2.02-2(1) Verschlüsselung von Daten: Kundendaten müssen grundsätzlich verschlüsselt auf den Speichermedien des Cloud Service Provider abgelegt werden können. Der Kunde muss hierfür ein Schlüsselmanagement betreiben und die entsprechenden Sicherheitskonzepte (z. B. das Kryptokonzept) mit dem Cloud Service Provider abstimmen. Für die Verschlüsselung sind ausnahmslos vertrauenswürdige Hard- und/oder Softwarekomponenten einzusetzen. Die Vertrauenswürdigkeit kann durch international anerkannte (Sicherheits-) Zertifikate belegt werden. S T R I D E Storage-Security-Appliances müssen für die Data-at-Rest-Sicherheit über Funktionen wie Datenverschlüsselung (Storage-Verschlüsselung), Zugangsschutz, Firewall, Logging und Auditing sowie Key-Management verfügen. Die Sicherheit und die Zuverlässigkeit der kryptographischen Maßnahmen und Komponenten sowie die Integrität verschlüsselt gespeicherter Daten ist regelmäßig zu überprüfen und zu nachzuweisen. M2.02-2(2) Sichere Trennung von (Multi-Mandanten-Fahigkeit): Komponenten, Diensten und Daten Die Informationssysteme des Cloud Service müssen eine strikte und sichere Trennung von Komponenten, Diensten, Anwendungen und Daten verschiedener Serviceabonnenten durchsetzen. Dazu zählen auch bspw. die sichere Authentifizierung zwischen Switchen, die Trennung von Mandanten auf Netzebene und die ausschließliche Verwendung von sicheren Zugriffsmechanismen für die Fernadministration sowie der Sicherstellung von Zugriffen auf Systemkonsolen nur über verschlüsselte Verbindungen. Eine Kompromittierung der Integrität ausführbarer Programme und/oder Programminstanzen darf nach Maßgabe zu erwartender Bedrohungen nicht unbemerkt bleiben. Der Zugang zu diesen Komponenten, insbesondere zu genutzten Speichermedien, darf nur ausdrücklich autorisierten Personen möglich sein (siehe M1.01). S T R I D E Anmerkung: Die Trennung von Mandanten und Ressourcen muss stringent und fehlerfrei beginnend mit der Anmeldung im ADL bis hin zum Informations-/Datenobjekt, auf welches durch die jeweilige Anwendung zugegriffen werden soll, durchgesetzt werden. Dazu braucht es eindeutige und zweifelsfreie elektronische Identitäten sowie sichere und nicht zu umgehende Authentifikationsprozeduren, mit denen einer Eskalation von Zugriffsrechten zuverlässig begegnet werden kann. M2.02-2(3) Sichere Konfiguration von Speicher-Arrays/SAN: Die Speicherressourcen des CSP müssen gegen die unbefugte Kenntnisnahme und den unbefugten Zugriff durch Dritte geschützt werden. Virtualisierte Speicherressourcen sind durch Segmentierung abzusichern und sicher zu konfigurieren, bspw. durch sicheres Zoning und/oder LUN Masquerading, so dass eine Überwindung der logischen Netzwerkseparierung sowie eine fehlerhafte Zuordnung von Speicherressourcen ausgeschlossen werden können. S T R I D E Anmerkung: Zur Sicherstellung der Vertraulichkeit der in der Cloud-Umgebung 74

75 Sicherheitsmaßnahmen für das Archiving SaaS Modell Teil 3: gespeicherten Informationen und Daten eines jeden einzelnen Mandanten, ist es erforderlich, dass der jeweilige Serviceabonnent zusammen mit dem CSP auf der Grundlage der Schutzbedarfsfeststellung des Serviceabonnenten prüft und festlegt, welche Form des Zoning und/oder Maskerading genutzt werden müssen. M2.02-2(4) Überprüfung der Integrität und Sicherstellung der Verwendbarkeit: Die Integrität gespeicherter Daten und die Lesbarkeit bzw. die Verwendbarkeit der Speichermedien (einschließlich der Integrität der SAN-Fabric) und der darauf befindlichen Daten sind regelmäßig und unabhängig vom Speicher- oder Aufbewahrungszeitraum zu überprüfen und zu protokollieren. M2.02-2(5) Datensicherung, Backup und Archivierung: Die gemäß M1.04-3(3) definierten Richtlinien sind so umzusetzen, dass erforderliche Datensicherungsmaßnahmen zu den definierten Intervallen unterbrechungsfrei und sicher stattfinden. Bei erhöhtem Schutzbedarf sind voneinander unabhängige Datensicherungssysteme (DSS) einzusetzen (bspw. ein DSS für Daten mit dem Schutzbedarf normal und ein DSS für Daten mit dem Schutzbedarf hoch ). Insbesondere bei der Nutzung von Backup- und Archivsystemen, bei welchen die Daten auf externe Datenträger gesichert werden (bspw. Datenbänder (Tapes) oder Festplatten), ist die zusätzliche Trennung und Kennzeichnung dieser Datensicherungen und Datenträger nach dem jeweiligen Mandanten erforderlich. S T R I D E S T R I D E Der CSP muss sicherstellen, dass die hierfür benötigten Systeme und Speicherkapazitäten uneingeschränkt zur Verfügung stehen und überwacht werden. Regelmäßige Backup-Maßnahmen müssen den Verlust gespeicherter Daten durch Ausfall oder Störungen von virtuellen und/oder physikalischen Ressourcen verhindern und eine unverzügliche Wiederaufnahme des Service in der zugesicherten Leistungsgüte gewährleisten. M2.02-2(6) Einstufung und Kennzeichnung von Daten: Die durch den Serviceabonnenten als schutzbedürftig definierten Informationen/Daten (sowohl die kritischen Kundendaten auf den Datenhaltungsschichten und -systemen, als auch die Konfigurationsdaten der involvierten Komponenten, siehe auch M1.03-3(1)), sind gemäß dem dazu gemeinsam erarbeiteten Konzept zu klassifizieren und zuverlässig zu kennzeichnen (digital classification label). Ziel ist die Anwendung der getroffenen Definitionen auf alle Daten des jeweiligen Serviceabonnenten, einschließlich der separat gespeicherten Konfigurationsdaten der für die Cloud Services des jeweiligen Mandanten relevanten Systeme und Komponenten. Hierzu können Anwendungen oder Scripte für Office-Anwendungen oder Dienste genutzt werden (bspw. die Kennzeichnung der Daten auf Grund der Gruppenzugehörigkeit des Erstellers/Besitzers oder aufgrund des Inhalts/der Schlagworte in einer Datei), welche die vom CSP etablierten Prozesse zur Einstufung und Kennzeichnung sowie zur Wahrung der Integrität unterstützen. S T R I D E Anmerkung: Die Kennzeichnung (Attribuierung) der Information und Daten auf der Grundlage der Schutzbedarfsfeststellung durch den Serviceabonnenten stellen eine entscheidende Voraussetzung für Regelungen bzgl. der Gewährung von Zugang und Zugriff auf diese Daten dar. Nur so ist eine benutzer- und systembestimmte Trennung von Mandanten und Akteuren eines Mandanten stringent durchsetzbar. M2.03 Schutz von Daten während der Kommunikation/des Transports 75

76 Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell M Die Informationssysteme des Cloud Service müssen vertrauenswürdige Kommunikationskanäle und Kommunikationsendpunkte für die Kommunikation mit dem Serviceabonnenten sowie der Datenübertragung zwischen den Servicekomponenten und -systemen einschließlich der Kommunikation mit involvierten Drittanbietern bereitstellen. M Vor dem Hintergrund der in Teil 2 dieses Sicherheitsprofils beschriebenen Bedrohungsszenarien sind dabei insbesondere folgende (Detail-) Aspekte zu berücksichtigen: M2.03-2(1) Schutz der Kommunikation und Kommunikationsendpunkte: Die Informationssysteme des Cloud Service müssen vertrauenswürdige Kommunikationskanäle und Kommunikationsendpunkte für die Kommunikation mit dem Serviceabonnenten sowie der Datenübertragung zwischen den Servicekomponenten und -systemen einschließlich der Kommunikation mit involvierten Drittanbietern bereitstellen. Der hierbei erwartete Funktionsumfang muss unter anderem die Verschlüsselung der Kommunikation, die zwingende Zugriffskontrolle für die Management-Schnittstelle(n), eine Switch-zu-Switch-Authentifikation und -Autorisierung sowie die Zugriffskontrolle auf etwaige Device-Level (Ports) umfassen. S T R I D E Die Vertrauenswürdigkeit muss durch eine ausreichende Verschlüsselung der Kommunikationskanäle, eine sichere Authentisierung der Kommunikationsendpunkte, eine sichere Authentifizierung der diese Kommunikationsverbindungen nutzenden Akteure, geeignete Maßnahmen zum Schutz der Authentizität von Kommunikationssitzungen sowie die Validierung importierter Daten unterstützt werden. Daher sind zu diesem Zweck ausschließlich sicherheitsgeeignete Technologien und Verfahren sowie vertrauenswürdige Kommunikationsanbieter (ISP) einzusetzen. Störungen der Kommunikation ausgelöst durch Fehlverhalten oder den Ausfall von Komponenten müssen angepasst an die vereinbarte Dienstgüte durch eine ausreichende redundante Auslegung der Kommunikationsressourcen, einschließlich der relevanten Netzwerkverbindungen und genutzten Plattformen, begegnet werden. Anmerkung: Für das Anwendungsszenario SaaS Archiving ist der Schutz der Informationen und Daten während der Kommunikation mit und in der Cloud-Umgebung des CSP besonders wichtig. Aus diesem Grund sind insbesondere die Kommunikationsverbindungen und die entsprechenden Kommunikationsendpunkte durch geeignete Maßnahmen ausreichend zu schützen, so dass ein nicht autorisierter Zutritt und Zugang nach Maßgabe zu erwartender Bedrohungen ausgeschlossen werden kann. Eine redundante Auslegung ermöglicht im Fall einer Kompromittierung die Schließung betroffener Kommunikationskanäle und den Wechsel auf nicht kompromittierte Kommunikationskanäle. M2.03-2(2) Überwachung der Aktivitäten in Netzwerken mittels NIDS (Network Intrusion Detection System): Die Kommunikation zwischen Abonnenten, Komponenten und Systemen des Cloud Service ist durch Netzwerk-basierte Intrusion Detection Systeme zu überwachen und zu protokollieren, um so auftretende Anomalien, Auffälligkeiten, Gefährdungen und Angriffe schnellstmöglich feststellen zu können. S T R I D E Die protokollierten Daten (sicherheitsrelevante Ereignisse) sollen umgehend und automatisch an geeignete SIEM-Systeme (Security Information and Event 76

77 Sicherheitsmaßnahmen für das Archiving SaaS Modell Teil 3: Management) weitergeleitet werden, um aus den korrelierten Informationen umgehend erforderliche (Gegen-) Maßnahmen initiieren zu können. Die Log-Daten sollen zuverlässig vor Manipulation geschützt werden. Die Log-Daten sollen zuverlässig über einen, den Zwecken angemessenen, Zeitraum vor Verlust geschützt werden. M2.03-2(3) Überwachung der Kommunikation mittels HIDS (Host-basierten Intrusion Detection Systemen): Zur Realisierung der Kommunikation zwischen Abonnenten, Komponenten und Systemen des Cloud Service muss die Steuerung der Datenströme (bspw. zur Annahme, Prüfung und Beantwortung von Anfragen) durch zentralisierte Systeme (bspw. für die Authentifizierung und Autorisierung) erfolgen. S T R I D E Diese Informationssysteme stellen aufgrund ihrer herausgehobenen und zentralen, für die Cloud Services entscheidenden Rolle besonders gefährdete und schützenswerte Objekte dar. Derartige Systeme sind deshalb zusätzlich zu M2.03-2(2) als operativ kritische Ressourcen mittels HIDS zu überwachen. Die protokollierten Daten (sicherheitsrelevante Ereignisse) sollen umgehend und automatisch an geeignete SIEM- Systeme (Security Information and Event Management) weitergeleitet werden, um aus den korrelierten Informationen erforderliche (Gegen-) Maßnahmen initiieren zu können. Die Log-Daten sollen zuverlässig vor Manipulation geschützt werden. Die Log-Daten sollen zuverlässig über einen, den Zwecken angemessenen, Zeitraum vor Verlust geschützt werden. M2.03-2(4) Schutz wichtiger Daten mittels DLPS (Data Loss Prevention System): Als besonders schützenswert eingestufte Daten und Informationen müssen nicht nur hinsichtlich ihrer sicheren Speicherung/Aufbewahrung, sondern auch während jeder Form der Kommunikation und des Austauschs dieser Inhalte zuverlässig geschützt werden. Hierzu sollen DLPS eingesetzt werden, welche nicht nur gegen externe Akteure prüfen und agieren, sondern auch die Nutzer der Cloud Services beim Umgang mit derartig sensiblen Informationen unterstützen. Der hierbei erwartete Funktionsumfang soll sich nicht nur auf die Entdeckung von Manipulationsversuchen sensibler Inhalte während der Kommunikation beschränken, sondern vor allem auch die Durchsetzung von Autorisierungs- und Datenschutzrichtlinien gewährleisten. S T R I D E Die Umsetzung dieser Richtlinien muss die sichere Verhinderung von nicht gewollter Kommunikation sensibler Inhalte und die Protokollierung und Weiterleitung der Auffälligkeiten an zentrale Überwachungs- und Managementinstanzen (bspw. ein SIEM-System) umfassen. Darüber hinaus soll aber auch die Benachrichtigung des verursachenden Akteurs, dass die aktuell initiierte Kommunikation so nicht erlaubt ist, unterstützt werden. DLP-Systemfunktionen müssen hierbei mindestens die aktive Prüfung der für den Download und/oder Upload auf externe bzw. nicht zuvor definierte Zielsysteme erlaubten Inhalte (einschließlich mobiler Endgeräte, wie bspw. Notebooks, Smartphones und USB-Sticks), als auch die Prüfung von Berechtigungen der Kommunikationsakteure (wer darf zu welchem Zweck was mit wem kommunizieren) umfassen. Anmerkung: DLPS stellen aktive Sicherheitskomponenten der für die Bereitstellung der Cloud Services notwendigen Netzwerke und der an diese Netze angeschlossenen 77

78 Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell Kommunikationsschnittstellen und Speicherbereiche (bspw. Speicher-Arrays und SAN sowie -Server) dar. DLP-Systeme sind daher für das Anwendungsszenario SaaS Archiving von besonderer Bedeutung. Mit ihrer Hilfe ist eine zuverlässige Kontrolle zulässiger Kommunikationspartner wie auch der Kommunikationsinhalte möglich. Damit wird nicht nur die erforderliche Trennung der Mandanten unterstützt, sondern auch die zwingende Authentifikation und Autorisierung einzelner Akteure sowie die Wahrung der Vertraulichkeit und der Integrität durch die Einschränkung bzw. eindeutige Definition zulässiger Kommunikation von sensiblen und schützenswerten Inhalten. M2.03-2(5) Regelmäßige Schwachstellen- und Penetrationstests: Die Sicherheit der Kommunikationsendpunkte muss durch regelmäßige Schwachstellenscans (vulnerabilty scanning) und Penetrationstests geprüft werden. Die dabei festgestellten Schwachstellen sind durch sicherheitsrelevante Patches und Updates von betroffenen Kommunikationssystemen unverzüglich zu beheben. Die Ergebnisse eines jeden Tests sind zu dokumentieren und vor Manipulation und vor Bloßstellung/ vor Einsicht- und Kenntnisnahme geschützt aufzubewahren sowie zur zeitnahen Aktualisierung und Anpassung von Sicherheitsrichtlinien einzusetzen. M2.04 Schutz von Informationssystemen M Die Informationssysteme des Cloud Service müssen eine sichere Authentifikation beim Zugriff auf Nutzerkonten, Komponenten und Systeme durchsetzen. Der Zutritt und Zugang zu sowie der Zugriff auf besonders kritische Systeme oder Anwendungen, wie Managementkonsolen, muss durch eine sichere Multi-Faktor-Authentifizierung und durch voneinander getrennte Zugriffspunkte (bspw. sollten Managementkonsolen nur über kryptographisch gesicherten Kommunikationsverbindungen erreichbar sein) geschützt werden. M Vor dem Hintergrund der in Teil 2 dieses Sicherheitsprofils beschriebenen Bedrohungsszenarien sind dabei insbesondere folgende (Detail-) Aspekte zu berücksichtigen: M2.04-2(1) Gesicherte Infrastruktur: Ein unbemerkter Austausch von Komponenten und Systemen des Cloud Service muss durch eine zuverlässige, kryptographisch gesicherte, gegenseitige Authentifizierung verhindert werden. Diese Absicherung sollte durch den Einsatz mehrerer, den Sicherheitszonen der genutzten Infrastruktur entsprechenden Zutrittskontrollsysteme unterstützt werden. Gemäß M1.01 muss der CSP formale Prozesse etablieren, welche den Zutritt und den Zugang zu Komponenten und Systemen des Cloud Service ausschließlich für autorisierte Personen ermöglichen. S T R I D E S T R I D E Der Zugriff auf diese Ressourcen (insbesondere bzgl. der Archivdatenträger) ist zu protokollieren und diese Protokolle sind sicher aufzubewahren und zuverlässig vor Manipulation zu schützen. Diese Protokolle sind über einen, den Zweck angemessenen Zeitraum vor Verlust zu schützen. Der Zutritt und Zugang auf diese Ressourcen (insbesondere bzgl. der Archivdatenträger) sollte ebenfalls protokolliert werden. Diese Protokolle sollten sicher aufbewahrt und über, den jeweiligen Zwecken angemessenen Zeitraum, vor Verlust oder Manipulation geschützt werden. M2.04-2(2) Schutz von Konfigurationsdaten: Die Sicherheitsfunktionen der Informationssysteme des Cloud Service müssen einen den (Sicherheits-) Richtlinien gemäß M2.02 zuverlässigen Schutz der 78 S T R

79 Sicherheitsmaßnahmen für das Archiving SaaS Modell Teil 3: Konfigurationsdaten von Komponenten, Schnittstellen und Systemen gewährleisten können. Die Integrität von Konfigurationsdaten muss regelmäßig überprüft werden. Ein nicht autorisierter und unbemerkter Zugriff auf Konfigurationsdaten darf nach Maßgabe zu erwartender Bedrohungen nicht möglich sein. I D E Änderungen an den Konfigurationsdaten dürfen nur von ausdrücklich autorisierten Akteuren (d.h. bspw. nur von den für diesen Mandanten zuständigen Administratoren) und nicht ohne eine vorangehende Multi-Faktor-Authentifizierung ausgeführt werden. Die Änderungen müssen protokolliert und die Protokolle zuverlässig, über einen den Zwecken angemessenen Zeitraum, vor Verlust oder Manipulation geschützt werden. M2.04-2(3) Überwachung kritischer Ressourcen: Aktivitäten und Zugriffe auf operativ kritische physische Ressourcen sind gemäß M2.03-2(2) und M2.03-2(3) durch Netzwerk- bzw. Host-basierte Intrusion Detection Systeme (NIDS/HIDS) zu überwachen und zu protokollieren. Die protokollierten Daten (sicherheitsrelevante Ereignisse) sollen umgehend und automatisch an geeignete SIEM- Systeme (Security Information and Event Management) weitergeleitet werden, um aus den dann korreliert zur Verfügung stehenden Informationen erforderliche (Gegen-) Maßnahmen umgehend initiieren zu können. S T R I D E Die Log-Daten und Protokolle sind über einen dem Zweck angemessenen Zeitraum zuverlässig vor Manipulation und Verlust zu schützen. M2.04-2(4) Schutz wichtiger Ressourcen mittels IPS (Intrusion Prevention System): Zusätzlich zu M2.03 sind wichtige Ressourcen der Cloud-Umgenung des CSP durch IP-Systeme so zu schützen, dass die durch NIDS/HIDS festgestellten Auffälligkeiten die sofortige Auslösung von zuvor definierten Aktionen (bspw. Blockade von Ports oder Verbindungen, Beendigung von Kommunikationsströmen und Versendung von Alarmen an entsprechende SIEM-Systeme und verantwortliche Akteure) zur Folge haben. S T R I D E Alle Aktionen von durch IPS initiierten Aktionen müssen automatisch durch das auslösende System protokolliert und sollen umgehend an geeignete SIEM- Systeme (Security Information and Event Management) weiterzuleiten. Die Log-Daten und Protokolle müssen zuverlässig vor Manipulation und Verlust geschützt werden. Anmerkung: Für das Anwendungsszenario SaaS Archiving ist der Schutz der Informationen und Daten während der Kommunikation mit und in der Cloud-Umgebung des CSP von besonderem Gewicht. Aus diesem Grund ist der Einsatz von IPS unabdingbar. Denn nur mittels dieser Intrusion Prevention Systeme kann zuverlässig ein nicht autorisierter Zugriff auf entsprechend schützenswerte Informationen und Daten des jeweiligen Dienstabonnenten festgestellt und ggf. verhindert werden. Zugleich unterstützt der Einsatz von IPS die Wahrung der Verfügbarkeit der für die entsprechenden Cloud- Dienste erforderlichen Komponenten des CSP. M2.04-2(5) Schutz kritischer Komponenten mittels HIPS (Host-based Intrusion Prevention System): Zusätzlich zu M2.03 und M2.04-2(3) sind kritische Komponenten der Cloud-Umgebung, d.h. Systeme, welche für den operativen Betrieb maßgeblich von Bedeutung sind (wie bspw. -Server, Metadaten- und Verzeichnissysteme und S T R I D E 79

80 Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell Sicherheitskomponenten wie RADIUS-Sever), durch HIP-Systeme so zu schützen, dass die durch NIDS/HIDS festgestellten Auffälligkeiten die sofortige Auslösung von zuvor definierten Aktionen (bspw. Beendigung von Diensten oder Anwendungen, Blockierung des eingehenden Verkehrs und Versendung von Alarmen an entsprechende SIEM-Systeme und verantwortliche Akteure) zur Folge haben. Alle durch das IPS initiierten Aktionen müssen automatisch durch das auslösende System zu protokolliert und sollen umgehend an geeignete SIEM- Systeme (Security Information and Event Management) weitergeleitet werden. Die Log-Daten und Protokolle müssen zuverlässig über einen, dem Zweck angemessenen, Zeitraum vor Manipulation und Verlust geschützt werden. M2.04-2(6) Schutz virtualisierter Ressourcen: Virtualisierte Ressourcen müssen zusätzlich zu den gemäß M2.04 definierten Richtlinien auch durch sicheres Zoning und / oder LUN Maskerading vor der unbefugten Kenntnisnahme und dem unbefugten Zugriff durch Dritte geschützt sowie permanent durch ein entsprechend ausgelegtes Monitoring überwacht werden. S T R I D E Sicherheitsupdates oder patches müssen unverzüglich getestet und eingespielt werden. Diese Maßnahmen müssen dokumentiert, die Dokumente (Protokolle) vor Verlust und Manipulation geschützt werden. Die Sicherstellung des Schutzes der virtualisierten Ressourcen muss auch die Durchsetzung der Maßgaben und Richtlinien gemäß M1.03, M1.04, M1.05 und M2.02 für alle VM-spezifischen Komponenten und Prozesse (bspw. den Zugriff auf VM-Management-Konsolen oder VM-Tools, die Verwaltung von VM User Accounts, die Konfiguration/Setup und die Verteilung von VMs und Virtual Appliances (VAPs), die Erstellung und Verwaltung von Snapshots, den Anschluss und die Trennung von virtuellen Geräten, die sichere Zuweisung von physikalischen Ressourcen, die Segmentierung von Speicherressourcen, die Vermeidung der Überwindung der logischen Netzwerkseparierung etc.) umfassen. M2.04-2(7) Redundanz von Ressourcen: Die Informationssysteme des Cloud Service sind, einschließlich der ggf. durch einen Internet Service Provider bereitgestellten Kommunikationsverbindungen, ausreichend redundant auszulegen, um auf Änderungsverlangen des Serviceabonnenten hinsichtlich der erforderlichen Rechen- oder Speicherkapazität unverzüglich durch Bereitstellung zusätzlicher virtueller und physischer Ressourcen reagieren zu können und um Störungen der Funktionalität oder den Ausfall von Komponenten durch die Bereitstellung alternativer Ressourcen und Kommunikationsverbindungen kompensieren zu können. M2.05 Incident Response Capability M Der Cloud Service Provider muss über die Fähigkeit (technische und organisatorische Ausrüstung) verfügen, sicherheitsrelevante Störfälle unverzüglich und angemessen zu behandeln. Das schließt die Vorbereitung auf sicherheitsrelevante Störfälle, die Entdeckung und Analyse, die Eindämmung, die Beseitigung der Ursachen und die 80 S T R I D E S T R I D E

81 Sicherheitsmaßnahmen für das Archiving SaaS Modell Teil 3: Wiederherstellung des ordnungsgemäßen Betriebs in der vereinbarten Leistungsgüte ausdrücklich ein. M Operative Log-Daten sollen in einem Security Information and Event Management System (SIEM) aggregiert und automatisch auf Auffälligkeiten (sicherheitsrelevante Ereignisse) bewertet sowie vor Manipulation und Verlust geschützt werden. Die so gewonnenen Erkenntnisse sind in regelmäßigen Abständen (bspw. monatlich oder halbjährlich), sowie auf Verlangen, dem Serviceabonnenten in Form eines auf die durch ihn genutzte Cloud-Umgebung hin angepassten Reports bereitzustellen. Personelle Sicherheitsmaßnahmen Index Titel und Beschreibung M3.01 Sicherheitsüberprüfung M Der Cloud Service Provider muss über formale und dokumentierte Richtlinien für die regelmäßige Sicherheitsüberprüfung seiner Mitarbeiter (siehe M1.01-2(2) und Geheimschutzhandbuch BMI) verfügen. Die Richtlinien sollen Ziele, Geltungsbereiche und je nach zugewiesenen Aufgabenbereichen und damit verbundenen Berechtigungen abgestufte Prüfkriterien, Rollen und Verantwortlichkeiten, die Koordination unterschiedlicher Unternehmenseinheiten sowie Informationswege beim Eintritt sicherheitsrelevanter Ereignisse oder fahrlässigen Verhaltens umfassen. M Auf der Grundlage dieser Richtlinien muss der Cloud Service Provider dokumentierte Prozesse etablieren, mit denen regelmäßige Sicherheitsüberprüfungen durchgesetzt werden. Die Durchführung der regelmäßigen Sicherheitsüberprüfung beinhaltet auch die Erstellung und die Pflege der aktenkundigen Nachweise bzgl. der Belehrung des überprüften Personals. M Der Cloud Service Provider muss gemäß M1.04-2(4) dokumentierte Prozesse etablieren, mit denen in regelmäßigen Abständen die Zuweisung von Berechtigungen überprüft wird. Für ausgeschiedene Mitarbeiter müssen die Authentifikationsdaten und zugewiesenen Berechtigungen unverzüglich und nachweislich gelöscht werden. M3.02 Überprüfung zugewiesener Berechtigungen und benötigter Identitäten (Accounts) M Auf der Grundlage der Richtlinien gemäß M1.01(1) muss der Cloud Service Provider dokumentierte Prozesse etablieren, mit denen in regelmäßigen Abständen bestehende digitale Identitäten und die erfolgte Zuweisung von Berechtigungen überprüft werden. Die Überprüfung darf nicht nur die Akteure des Cloud Service STRIDE S T R I D E S T R I D E 81

82 Teil 3: Sicherheitsmaßnahmen für das Archiving SaaS Modell Providers umfassen, sondern ist auch für die Administratoren des Serviceabonnenten und etablierte Dienste (Service Accounts) durchzuführen. M Gemäß M1.04-2(4) müssen für ausgeschiedene Mitarbeiter oder nicht mehr unter Vertrag stehende Servicepartner die Authentifikationsdaten und zugewiesenen Berechtigungen unverzüglich und nachweislich gelöscht werden. M3.03 Sicherheitsverhalten und Sicherheitstraining M Der Cloud Service Provider muss über formale und dokumentierte Richtlinien für das erforderliche Sicherheitsverhalten und Sicherheitstraining der Mitarbeiter entsprechend den ihnen zugewiesenen Aufgaben und Verantwortlichkeiten verfügen. M Die Richtlinien sollen Ziele, Geltungsbereiche, Rollen und Verantwortlichkeiten, die Koordination unterschiedlicher Unternehmenseinheiten, Informationswege und einzuleitende (Sofort-) Maßnahmen beim Eintritt sicherheitsrelevanter Ereignisse oder fahrlässigen Verhaltens umfassen. M Die Richtlinien müssen regelmäßig durch den CSP in Bezug auf die aktuell bestehenden Erfordernisse sowie die gegebene Sicherheitslage hin angepasst und überprüft werden. M Auf der Grundlage der Richtlinien muss der Cloud Service Provider Prozesse etablieren, welche die Umsetzung unterstützen. Dazu gehören: S T R I D E die regelmäßige und dokumentierte Einweisung und Schulung in die sichere Konfiguration, den sicheren Betrieb und das sichere Management der für den Service erforderlichen Systeme und Komponenten, die regelmäßige und dokumentierte Unterweisung hinsichtlich der Beachtung und Einhaltung von Sicherheitsmaßnahmen, die regelmäßige und dokumentierte Unterweisung hinsichtlich der Beachtung und Einhaltung datenschutzrechtlicher Regelungen und Anforderungen, die regelmäßige und Bedrohungen und das regelmäßige und dokumentierte Training des Verhaltens beim Auftreten sicherheitsrelevanter Ereignisse. dokumentierte Unterrichtung über bekannte Besonderer Fokus soll dabei sein, die Mitarbeiter zu befähigen, Social Engineering Attacken, die gerade bei mehrstufigen Angriffen und APTs eine vorbereitende Funktion haben, zu erkennen und ihnen durch entsprechende Prozesse beim CSP zu begegnen. 82

83 Kreuzreferenztabellen für das SaaS Archiv-Modell Teil 4: Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell 4.1 Einleitung In Teil 2 dieses Sicherheitsprofils wurden für ein als Software-as-a-Service in einer Cloud Computing Umgebung zur Verfügung gestelltes Archivsystem dreizehn wichtige Bedrohungen für die Schichten des IETF Cloud Stacks identifiziert, beschrieben und in Form von Steckbriefen detailliert für die nachfolgend aufgeführten Bedrohungen und Komponenten des IETF Cloud Stacks beschrieben: für das Access & Delivery Layer: Spoofing, Repudiation, Information Disclosure, für das Cloud Service Layer: Tampering und Information Disclosure für die Cloud Management Plane: Tampering, Denial of Service und Elevation of Privilege für das Cloud Resource & Orchestration Layer: Tampering, Information Disclosure, Denial of Service und Elevation of Privilege, für die Kommunikation des Serviceabonnenten mit der Access & Delivery Layer Denial of Service. In Teil 3 dieses Dokuments Sicherheitsprofil für ein SaaS Atchivsystem wurden Sicherheitsmaßnahmen organisatorischer, technischer und personeller Natur definiert, die geeignet sind, den in Teil 2 genannten Bedro hungen entgegen zu wirken. Das vorliegende Dokument, Teil 4 des Sicherheitsprofils für ein SaaS Archivsystem, stellt die Sicherheitsmaßnahmen den Bedrohungen gemäß der STRIDE Klassifikation in einer Referenztabelle gegenüber. Damit lässt sich nachvollziehen, inwieweit durch die Sicherheitsmaßnahmen eine Abdeckung und damit auch eine erfolgreiche Abwehr der aufgezeigten Bedrohungen möglich wird. STRIDE ist ein Akronym und steht für Spoofing (nachahmen, Vortäuschen einer Identität), Tampering (fälschen, manipulieren von Daten), Repudiation (Abstreiten einer Handlung), Information Disclosure (aufdecken, veröffentlichen von Informationen), Denial of Service (Dienstverweigerung) und Elevation Privilege (unzulässige Erweiterung von Rechten). STRIDE wurde 2002 von Microsoft für die Klassifizierung von Angriffsmustern entwickelt. 83

84 Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell 4.2 Kreuzreferenztabellen für SaaS Archivsystem In den nachfolgenden Tabellen werden folgende Abkürzungen bzw. Symbole verwendet: ADL Access & Delivery Layer CSL Cloud Service Layer CMP Cloud Management Plane RCOL Resource Control & Orchestration Layer Comm SEU-ADL Kommunikation zwischen Subscriber End User und Access & Delivery Layer Für die Abdeckung der Bedrohungen durch die in Teil 3 des Dokuments vorgeschlagenen Sicherheitsmaßnahmen Die Sicherheitsmaßnahme dient unmittelbar der Abwehr einer Bedrohung. Die Sicherheitsmaßnahme vermindert (begrenzt) eine Bedrohung. 84

85 Kreuzreferenztabellen für das SaaS Archiv-Modell Teil 4: 85

86 Maßnahmen M M1.01-2(1) M1.01-2(2) M M1.03-3(1) M1.04-3(2) M1.04-3(3) M1.04-3(5) Index 01 02/2 02/ /4 02/5 03/1 M1.03-3(2) M1.03-3(3) M1.03-3(4) M1.04-3(1) M1.04-3(4) Datenmanipulation durch nicht kommunizierte, nicht abgestimmte Prozesse 02/1 Unbeabsichtigte Datenmanipulation 01/4 Datenmanipulation auf Grund einer ungenügenden Trennung der Mandanten Datenmanipulation auf Grund einer ungenügenden Trennung des Zugrifs auf die Funktionalitäten in der CMP 01/3 Datenmanipulation durch Hacking der RCOL Architektur Unbeabsichtigte Datenmanipulation CMP Veränderung der Konfgurationsdaten Datenmanipulation durch Eskalation von Zugrifsrechten Spoofing Datenmanipulation durch Hacking der CSP Architektur Datenmanipulation auf Grund einer ungenügenden Trennung der Mandanten 01/2 Datenmanipulation durch Hacking der CSP Architektur 01/1 Datenmanipulation durch unsichere Schnittstellen Layer: Weiterleitung des abgefangenen Datenverkehrs unter Verwendung gefälschter Identifkationsmerkmale STRIDE: Abfangen des Datenverkehrs Missbrauch ungeschützter bzw. nicht beendeter Sitzungen (Sessions) Missbrauch von Zugrifsrechten mittels gefälschter Authentifkationsdaten bei der Anmeldung (Login) Gefährdungen Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell Spoofing und Tampering für ADL, CSL, CMP und RCOL Referenztabelle SaaS Archiving Tampering ADL CSL RCOL 03 03/2 04/1 04/2 04/ /4 04/5

87 Maßnahmen M2.01 M2.03-2(1) 87 M2.03-2(2) M2.03-2(3) M2.03-2(5) M2.04-2(3) M2.04-2(4) M2.04-2(5) M2.05 Index M2.04-2(1) 01 02/ /4 02/ 5 03/1 M2.02-2(1) M2.02-2(2) M2.02-2(3) M2.02-2(4) M2.02-2(6) M2.03-2(4) M2.04-2(2) M2.04-2(6) M2.04-2(7) M2.02-2(5) Datenmanipulation durch nicht kommunizierte, nicht abgestimmte Prozesse 02/2 Unbeabsichtigte Datenmanipulation 02/1 Datenmanipulation auf Grund einer ungenügenden Trennungder Mandanten Datenmanipulation auf Grund einer ungenügenden Trennungdes Zugrifs auf die Funktionalitäten in der CMP 01/ 4 Datenmanipulation durch Hackingder RCOL Architektur Unbeabsichtigte Datenmanipulation 01/ 3 Veränderungder Konfgurationsdaten Datenmanipulation durch Eskalation von Zugrifsrechten Spoofing Datenmanipulation durch Hacking der CSP Architektur Datenmanipulation auf Grund einer ungenügenden Trennungder Mandanten 01/2 Datenmanipulation durch Hacking der CSP Architektur 01/1 Datenmanipulation durch unsichere Schnittstellen Layer: Weiterleitungdes abgefangenen Datenverkehrs unter Verwendung gefälschter Identifkationsmerkmale Missbrauch ungeschützter bzw. nicht beendeter Sitzungen (Sessions) STRIDE: Abfangen des Datenverkehrs Missbrauch von Zugrifsrechten mittels gefälschter Authentifkationsdaten bei der Anmeldung (Login) Gefährdungen Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell Tampering ADL CSL CMP RCOL 03 03/2 04/ 1 04/2 04/ /4 04/5

88 M aßnahme n 88 M3.01 M3.02 M3.03 Index 01 02/ /4 02/5 03/1 Datenmanipulation durch nicht kommunizierte, nicht abgestimmte Prozesse 02/2 Unbeabsichtigte Datenmanipulation 02/1 Datenmanipulation auf Grund einer ungenügenden Trennungder Mandanten Datenmanipulation auf Grund einer ungenügenden Trennungdes Zugrifs auf die Funktionalitäten in der CMP 01/ 4 Datenmanipulation durch Hackingder RCOL Architektur Unbeabsichtigte Datenmanipulation 01/ 3 Veränderungder Konfgurationsdaten Datenmanipulation durch Eskalation von Zugrifsrechten Spoofing Datenmanipulation durch Hacking der CSP Architektur Datenmanipulation auf Grund einer ungenügenden Trennungder Mandanten 01/2 Datenmanipulation durch Hacking der CSP Architektur 01/1 Datenmanipulation durch unsichere Schnittstellen Layer: Weiterleitungdes abgefangenen Datenverkehrs unter Verwendung gefälschter Identifkationsmerkmale Missbrauch ungeschützter bzw. nicht beendeter Sitzungen (Sessions) STRIDE: Abfangen des Datenverkehrs Missbrauch von Zugrifsrechten mittels gefälschter Authentifkationsdaten bei der Anmeldung (Login) Gefährdungen Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell Tampering ADL CSL CMP RCOL 03 03/2 04/ 1 04/2 04/ /4 04/5

89 Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell Repudiation and Information Disclosure für ADL, CSL und RCOL Repudiation STRIDE: Information Disclosure ADL Layer: CSL M M1.01-2(1) Maßnahmen M1.03-3(2) M1.03-3(4) M1.04-3(2) M1.04-3(3) M1.04-3(4) M1.04-3(5) 89 M1.03-3(3) Unsichereoder fehlerhaftekonfguration der Segmentierung Fehlendes bzw. Ungenügendes StorageSecurity Konzept Unsichere/ nicht kontrollierte Kommunikationsverbindungen Unzureichende/ fehlerhafte Zuordnungvon SAN-Ressourcen 07/2 Fehlendes Sicherheitsbewusstsein 07/1 Unzureichende Erfahrung/ Fehlendes Sicherheitsbewusstsein 06/4 Ungeeignete Technologien 06/3 06 M1.03-3(1) M1.04-3(1) Ungenügende Mandantentrennung 06/2 Unsicherer Datenaustausch 06/1 Fehlende Verschlüsselungsverfahren 05/4 Ungeeignetes Rechte- und Rollenkonzept Unsichere Datenhaltungsnetzwerke Und -systeme 05/3 05 M1.01-2(2) M1.02 Einsatz von ungeeignetem, nicht sicherheitsüberprüftem Personal 05/2 Unzureichender Schutz von Protokolldaten Unzureichende Protokollierung 05/1 Index Unzureichender Schutz von Authentifkationsdaten Unsichere Authentisierung Gefährdungen RCOL 07/3 07/4 08/1 08/2 08/3 08/4 08/

90 Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell Repudiation STRIDE: Information Disclosure ADL Layer: CSL M2.01 M2.02-2(1) M2.02-2(2) M2.02-2(3) Fehlendes bzw. Ungenügendes StorageSecurity Konzept Unsichere/ nicht kontrollierte Kommunikationsverbindungen Unzureichende/ fehlerhafte Zuordnungvon SAN-Ressourcen 07/2 Unsichereoder fehlerhaftekonfguration der Segmentierung 07/1 Fehlendes Sicherheitsbewusstsein 06/4 Unzureichende Erfahrung 06/3 06 Ungeeignete Technologien 06/2 Ungenügende Mandantentrennung 06/1 Unsicherer Datenaustausch 05/4 Fehlende Verschlüsselungsverfahren Unsichere Datenhaltungsnetzwerke Und -systeme 05/3 05 Ungeeignetes Rechte- und Rollenkonzept Einsatz von ungeeignetem, nicht sicherheitsüberprüftem Personal 05/2 Unzureichender Schutz von Protokolldaten Unzureichende Protokollierung 05/1 Index Unzureichender Schutz von Authentifkationsdaten Unsichere Authentisierung Gefährdungen RCOL 07/3 07/4 08/1 08/2 08/3 08/4 08/ M2.02-2(4) M2.02-2(5) Maßnahmen M2.02-2(6) M2.03-2(1) M2.03-2(2) M2.03-2(3) M2.03-2(4) M2.03-2(5) M2.04-2(1) M2.04-2(2) M2.04-2(3) M2.04-2(4) M2.04-2(5) M2.04-2(6) M2.04-2(7) M

91 MaßNahme n 91 M3.02 M3.03 Index M /1 06/2 06 Unsichere / nicht kontrollierte Kommunikationsverbindungen Unzureichende / fehlerhafte Zuordnung von SAN-Ressourcen 07/2 Fehlendes bzw. Ungenügendes Storage Security Konzept 07/1 Unsichere oder fehlerhafte Konfguration der Segmentierung 06/4 Fehlendes Sicherheitsbewusstsein 06/3 Unzureichende Erfahrung Repudiation Ungeeignete Technologien Ungenügende Mandantentrennung 05/4 Unsicherer Datenaustausch 05/3 Fehlende Verschlüsselungsverfahren Layer: Ungeeignetes Rechte- und Rollenkonzept Unsichere Datenhaltungsnetzw erke Und -systeme 05/2 Einsatz von ungeeignetem, nicht sicherheitsüberprüftem Personal 05/1 Unzureichender Schutz von Protokolldaten Unzureichende Protokollierung STRIDE: Unzureichender Schutz von Authentifkationsdaten Unsichere Authentisierung Gefährdungen Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell ADL Information Disclosure CSL RCOL 07 07/3 07/4 08/1 08/2 08/ /4 08/5

92 Maßnahmen M M1.01-2(1) M1.01-2(2) M M1.03-3(2) M1.03-3(3) M1.04-3(1) M1.04-3(2) M1.04-3(3) M1.04-3(4) M1.04-3(5) Ausfall durch nicht kommunizierte, nicht abgestimmte Prozesse Unzureichendes oder fehlendes Archivsystemkonzept Ausfall/Störung durch den Einsatz zueinander inkompatibler Hardware Ausfall durch den Verlust von Daten Ausfall/Störung beim ISP Unsichere, nicht redundant Gestaltete Architektur RCOL Index 09/1 09/2 09/ /4 09/5 10/1 10/2 M1.03-3(1) M1.03-3(4) 10 10/3 11/1 11/ /3 11/4 12/ /2 13/1 Missbrauch von Berechtigungen Fehlendes Sicherheitsbewusstsein Denial of Service Fehlende Mandanten-Trennung/ Trennung von Zuständigkeiten (Separation of Duties) Missbrauch von Berechtigungen Dienstverweigerung durch Sperrung von Benutzerkonten CMP Unzureichend überw achte & gesicherte Kommunikationsverbindungen Unsichere, nicht redundant Gestaltete Architektur STRIDE: Ausfall durch nicht kommunizierte, nicht abgestimmte Prozesse Fehlende Mandanten-Trennung/ Trennung von Zuständigkeiten (Separation of Duties) Ausfall von Komponenten in der CMP Gefährdungen Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell Denial of Service, Elevation of Privilege für CMP, RCOL und Communication SEU-ADL Layer: Elevation of Privilege Comm SEU-ADL CMP RCOL 13 13/2

93 Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell Denial of Service STRIDE: Elevation of Privilege Layer: Comm SEU-ADL RCOL RCOL Ausfall durch den Verlust von Daten Ausfall/Störungbeim ISP Unsichere, nicht redundant Gestaltete Architektur 10/2 10/3 11/1 11/2 M2.01 M2.02-2(3) M2.02-2(5) Maßnahmen M2.02-2(6) M2.03-2(1) M2.03-2(2) M2.03-2(3) M2.03-2(4) M2.03-2(5) M2.04-2(1) M2.04-2(2) M2.04-2(3) M2.04-2(4) M2.04-2(5) M2.04-2(6) M2.04-2(7) M M2.02-2(2) M2.02-2(4) 10 11/3 11/4 12/ /2 13/ /2 13 Missbrauch von Berechtigungen Ausfall/Störungdurch den Einsatz zueinander inkompatibler Hardware 10/1 Fehlendes Sicherheitsbewusstsein Unzureichendes oder fehlendes Archivsystemkonzept 09/5 FehlendeMandanten-Trennung/ Trennungvon Zuständigkeiten (Separation of Duties) Ausfall durch nicht kommunizierte, nicht abgestimmte Prozesse 09/ 4 09 Missbrauch von Berechtigungen Dienstverweigerungdurch Sperrungvon Benutzerkonten 09/ 3 Unzureichend überwachte &gesicherte Kommunikationsverbindungen Unsichere, nicht redundant Gestaltete Architektur 09/ 2 Ausfall durch nicht kommunizierte, nicht abgestimmte Prozesse Fehlende Mandanten-Trennung/ Trennungvon Zuständigkeiten (Separation of Duties) 09/1 Index M2.02-2(1) CMP Ausfall von Komponenten in der CMP Gefährdungen CMP

94 M aßnahme n M3.02 M / 2 Dienstverweigerungdurch Sperrungvon Benutzerkonten 09/1 Unsichere, nicht redundant Gestaltete Architektur Fehlende Mandanten-Trennung/ Trennungvon Zuständigkeiten (Separation of Duties) M3.01 Ausfall von Komponenten in der CMP Gefährdungen 09/ 3 09/ 4 Unzureichendes oder fehlendes Archivsystemkonzept Ausfall/Störungdurch den Einsatz zueinander inkompatibler Hardware Ausfall durch den Verlust von Daten Ausfall/Störungbeim ISP Unsichere, nicht redundant Gestaltete Architektur 10 Ausfall durch nicht kommunizierte, nicht abgestimmte Prozesse 09/5 10/1 10/2 10/3 11/1 11/2 11 RCOL 11/3 11/4 12/ /2 13/1 Missbrauch von Berechtigungen CMP Fehlendes Sicherheitsbewusstsein Denial of Service Fehlende Mandanten-Trennung/ Trennungvon Zuständigkeiten (Separation of Duties) Missbrauch von Berechtigungen Unzureichend überwachte &gesicherte Kommunikationsverbindungen STRIDE: Ausfall durch nicht kommunizierte, nicht abgestimmte Prozesse Teil 4: Kreuzreferenztabellen für das SaaS Archiv-Modell Layer: Elevation of Privilege Comm SEU-ADL CMP RCOL 13 13/2

95 Steckbriefe Teil 5: Teil 5: 5.1 Steckbriefe Spoofing im Access & Delivery Layer Komponente Access & Delivery Layer (ADL) Das Access and Delivery Layer auf der Seite des Serviceproviders stellt Funktionen und allgemeine Infrastrukturkomponenten bereit, die dem Serviceabonnenten den Zugriff und die Nutzung des Archivsystem-Service ermöglichen. Dazu gehören sowohl Nutzerportale wie auch Servicegateways zur Steuerung und Kontrolle der Zugriffe. Da die Nutzung überwiegend über das Internet erfolgt, umfasst diese Schicht im Allgemeinen auch Netzwerkkomponenten, die in der Regel durch Netzprovider als beteiligte Dritte zur Verfügung gestellt werden. Bedrohung Spoofng Vortäuschung falscher Identitäten / Missbrauch fremder Identitäten Spoofng im Access & Delivery Layer Spoofng stellt für das Access & Delivery Layer (ADL) eine der größten Bedrohungsflächen dar. Die erfolgreiche Verwendung vorgetäuschter oder manipulierter persönlicher und / oder technischer Identitäten ist, verglichen mit der Kompromittierung kompletter Cloud Infrastrukturen, eine einfachere und oftmals unauffälligere Methode, um nachhaltig und im großen Ausmaß Zugriff auf Speichernetze zu erlangen. Sobald ein Angreifer Kenntnis oder Zugriff auf Authentifkations- und/oder Autorisierungsdaten erhält, ist er imstande Aktivitäten und Transaktionen zu belauschen sowie Zugang zu gespeicherten Daten zu erhalten. Erfolgreiches Spoofng ist überdies möglicher Ausgangspunkt für weitere Bedrohungen wie beispielsweise Tampering, Denial of Service, Information Disclosure und / oder Repudiation. Im einfachsten Fall wird ein externer Angreifer versuchen, mittels vorgetäuschter Kommunikationsverbindungen, wie zum Beispiel durch falsche s, (Support-) Websites oder Anrufe, den jeweiligen Akteur zur Aufdeckung bzw. Weitergabe dieser Informationen zu bewegen. Innentäter mit Administratorrechten sind in besonderer Weise für den Zugriff auf Authentifkations- und Autorisierungsdaten privilegiert. Eine weitere Möglichkeit für Spoofng dies gilt natürlich auch für Innentäter (vor allem Subscriber und Cloud Service Provider Administratoren) ist, mittels unbemerkter ManIn-The-Middle -Attacken die Kontrolle über die Datenwege bzw. den Zugriff auf entscheidende Systemkomponenten zu erlangen. Die missbräuchliche oder auch nur fahrlässige Handhabung von Hersteller-Tools zur Administration von Speichersystemen erleichtern den Zugriff auf den HBA einer Speicherlösung die Manipulation von WWNs sowie den unbefugten Zugriff auf Daten anderer Mandanten. Nicht von ungefähr wird deshalb die Bedrohung durch Spoofng durch die Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 als eine nach wie vor essentielle Bedrohung benannt. Besondere Spoofng-Attacken bzgl. des ADL für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Spoofng-Akteure der Subscriber End User (SEU), der Subscriber Administrator (SAD), der Cloud Service Provi 95

96 Teil 5: Steckbriefe der Administrator (CSA), der Sub-Provider Administrator (SPA) oder auch Innentäter des ISP in Betracht. Dabei lassen sich vor allem folgende Einzelbedrohungsszenarien für Spoofng im Access & Delivery Layer erkennen: 1. Missbrauch von Zugrifsrechten mittels fremder bzw. gefälschter Authentifkationsdaten bei der Anmeldung (Login) der SaaS Archivsystem-Anwendung Die Anmeldung als gespoofter SEU könnte den unbefugten Zugriff auf einzelne, nicht zuletzt auch vertrauliche Daten zur Folge haben. Die Anmeldung als gespoofter SAD könnte darüber hinaus den Zugriff auf die Benutzerverwaltung des SaaS Archivsystems unterstützen, wodurch dann nicht nur die Kenntnisnahme, der Diebstahl oder die Manipulation von Daten, sondern darüber hinaus auch die Manipulation von Zugangsdaten der Benutzer möglich wäre. Die Anmeldung als gespoofter CSP-Administrator könnte darüber hinaus, je nach den diesem Benutzerkonto zugewiesenen Berechtigungen den Zugriff auf Komponenten und Daten der SaaS Archivsystem-Anwendung zur Folge haben (zu Test-, Prüf- und Abnahmezwecken, sowie für erforderliche Support-Szenarien, verfügen CSP-Administratoren in der Regel auch über ein SaaS Archivsystem-Login). Der Internet Service Provider (ISP) und der CSP Sub-Provider sollten in der Regel über keine SaaS Archivsystem-Benutzerkonten verfügen und werden daher hier nicht weiter betrachtet. 2. Missbrauch ungeschützter bzw. nicht beendeter Sitzungen (Sessions) Mit Hilfe der durch abgefangene Kommunikation (Sniffing) erlangten Informationen und/oder der durch Login erzeugten Sitzungs-Cookies (z. B. via Wireshark), werden die zugehörigen Webservices neu geladen, indem diese Sitzungs-Cookies mittels eines Cookie Injectors im Browser platziert werden. Mit einem unbemerkten Zugriff auf Komponenten in der Cloud Architektur, welche die einzelnen Sitzungen verwalten (z. B. Terminalserver etc.), werden Sitzungen übernommen. Die Auswirkungen sind abhängig, ähnlich wie unter Ziffer 1 beschrieben, von den Berechtigungen, welche dem Benutzerkonto, dass diese Sitzung eröffnet hat, zugewiesen sind, da ein Angreifer dann auch nur diese ausnutzen kann. 3. Abfangen des Datenverkehrs Durch Vortäuschung einer gefälschten Login-Adresse. Durch Vortäuschung eines legitimierten Empfängers und somit Um- bzw. Weiterleitung des Datenverkehrs in Richtung einer gefälschten bzw. unwahren persönlichen und / oder technischen Identität (z. B. mit SSL Strip). Dieses Szenario wirkt sich vor allem auf die Akteure SEU und SAD negativ aus und hätte, je nach Verhaltensweise des betroffenen Akteurs, bis zur Feststellung dieser Täuschung, Auswirkungen, welche maßgeblich vom Aufbau und vom Umfang der Fälschung anhängig sind. 4. Weiterleitung des zuvor abgefangenen Datenverkehrs unter Verwendung von gefälschten Identifkations- / Absendermerkmalen Dieses Szenario stellt gegebenenfalls den bedrohlichsten zu erwartenden Fall dar, da es sich hierbei um einen unerkannten Teilnehmer auf dem Kommunikationsweg handelt. 96 Die Realisierung dieser Bedrohung setzt natürlich die erfolgreiche Beschaffung von Informationen voraus, welche es ermöglichen, sich einerseits unerkannt auf der infrage kommenden Kommunikationsverbindung etablieren zu können und um andererseits die abgefangenen, aber unveränderten Informationen dann mittels gestoh

97 Steckbriefe Teil 5: lener oder gefälschter Absenderkennung zur SaaS Archivsystem-Anwendung weiterleiten zu können. Bei unverschlüsselter bzw. nicht ausreichend verschlüsselter Kommunikation könnte das auch der ISP- sowie jeder SAD und CSP-Administrator mit dem erforderlichen Wissen. Abhängig vom tatsächlichen Schutz der Leitungs- und Paket-orientierten Kommunikation zwischen dem Serviceabonnenten und dem Service Provider, d. h. werden sichere Protokolle verwendet, sind sowohl die Kommunikationsverbindung wie auch die über diese Verbindung transportierten Daten verschlüsselt. Anderenfalls können je nach dem Einstiegspunkt des Angreifers ggf. Anmeldeinformationen aller der sich über die betroffene Kommunikationsverbindung agierenden Nutzer und die durch diese Akteure an die SaaS Archivsystem-Anwendung gesendeten Daten kompromittiert werden. Eintrittswahrscheinlichkeit gem. ALARP Schadenswirkung gem. ALARP WAHRSCHEINLICH HOCH bis SEHR HOCH Risikobewertung INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU-Prozesse, SAD-02 und SAD-03, CSP-01/1, CSP-01/2 und CSP-04 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: SEU-01, SAD-02, Anmeldung der CSP-Administratoren Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, AES-01, AES-02, AES-03, AES-05, AES-06, AES-07, AES-09, AES-13, NCS-01, NCS-02, NCS-03, DSS-01, DSS-02, DSS-03, DSS-05, DSS-06, DSS-07, DSS-09, PKI-01, PKI-02, PKI-03, IDM-01, IDM-02, IDM-03, IDM-06, SIM-01, SIM-02, SIM-04, SIM-05, BCM-01, BCM-03, PIM-01, PIM-02, PIM-03, SCM-01, HRR-01, HRR-02 Restrisiken Unsicherer Umgang mit Benutzerkennungen auf der Seite des Subscribers und des Sub-Providers. Fahrlässiges sowie vorsätzlich böswilliges Verhalten auf der Seite des Subscribers, des Sub-Providers, des ISP und durch die CSP- Administratoren. Ungenügend bzw. unzureichend gesicherte Kommunikationsverbindungen in der Verantwortung des Subscribers, des Sub-Providers und des ISP. Ungenügend bzw. unzureichend gesicherte Systemkomponenten auf der Seite des Subscribers, des Cloud Service Providers, des Sub-Providers und des ISP. Noch näher zu betrachtende Bereiche 97

98 Teil 5: Steckbriefe In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der einzelnen Akteure, sowie deren Umsetzung und Kontrolle, sollten die im Folgenden benannten Themen Gegenstand weiterer Betrachtungen sein: 98 Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: das Cloud Architekturkonzept des CSP, insbesondere bzgl. des User Portals und der Service Gateways sowie der Inter-Cloud Funktionalitäten die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich der Gestaltung und Umsetzung von Berechtigungs- und Rollenkonzepten, die Sicherheitsmaßnahmen des ISP und die Vertrags- und SLA-Gestaltung mit dem ISP. Etablierte Maßnahmen zur Reduzierung der Möglichkeiten für Angreifer, die für ein erfolgreiches Spoofng erforderlichen Informationen erhalten zu können und in diesem Zusammenhang die detaillierte Überprüfung und ggf. Anpassung der folgenden Aspekte: der sichere Umgang und die sichere Kommunikation von Kennwörtern und Benutzerkennungen, um beispielsweise -Spoofng und andere kommunikationsbasierte, zur Informationsgewinnung gedachten und zur Vorbereitung eines erfolgreichen Spoofngs erforderlicher Einzelbedrohungen ausschließen zu können, die strikte Trennung und auf den tatsächlich erforderlichen Umfang reduzierten Berechtigungen je Akteur, sichere und zuverlässige Prozesse Berechtigungsverwaltung sowie sicheres Session Handling. bzgl. der Benutzer- und Trotz umgesetzter technischer und organisatorischer Sicherheitsmaßnahmen kann jedoch das Eintreten folgender Einzelgefährdungen nicht völlig ausgeschlossen werden: Blind Spoofng, Non-Blind Spoofng (aus dem gleichen Sub-Netzwerk), Referrer-Spoofng, Content-Spoofng Spoofng), Man In The Middle - (Connection Hijacking) Attacken, welche dann: (Pishing, DHTML Spoofng, Website Spoofng, SSL Hijacking (SSL Strip), Session Hijacking (Cookie Stealing, TCP Session Hijacking), Blind TCP/IP Hijacking, Snarfng, URL

99 Steckbriefe Teil 5: Pharming, und somit den Zugriff auf SaaS Archivsystem-Daten ermöglichen, Trotz umgesetzter technischer und organisatorischer Sicherheitsmaßnahmen kann darüber hinaus das Eintreten folgender Einzelgefährdungen nicht völlig ausgeschlossen werden: Man In The Middle - Attacken, welche dann: ARP Spoofng (ARP Cache Poisoning), MAC Spoofng, DNS Spoofng (DNS Cache Poisoning), DHCP Spoofng (das Vortäuschen eines DHCP-Servers) WWN Spoofng und somit das Mitlesen übertragener Informationen, sofern diese nicht verschlüsselt sind, ermöglichen. Trotz umgesetzter technischer und organisatorischer Sicherheitsmaßnahmen kann das Eintreten folgender Einzelgefährdungen nicht völlig ausgeschlossen werden, die häufg für Denial of Service-Attacken genutzt werden: IP Spoofng (Flooding), ARP Spoofng. 99

100 Teil 5: Steckbriefe 5.2 Repudation im Access & Delivery Layer Komponente Access & Delivery Layer (ADL) Das Access and Delivery Layer auf der Seite des Serviceproviders stellt Funktionen und allgemeine Infrastrukturkomponenten bereit, die dem Serviceabonnenten den Zugriff und die Nutzung des Archivsystem-Service ermöglichen. Dazu gehören sowohl Nutzerportale wie auch Servicegateways zur Steuerung und Kontrolle der Zugriffe. Da die Nutzung überwiegend über das Internet erfolgt, umfasst diese Schicht im Allgemeinen auch Netzwerkkomponenten, die in der Regel durch Netzprovider als beteiligte Dritte zur Verfügung gestellt werden. Bedrohung Repudiation Abstreiten einer Handlung Repudiation im Access & Delivery Layer Repudiation stellt eine nicht zu unterschätzende Bedrohungsfläche für das Access & Delivery Layer (ADL) dar. Im ADL wird der maßgeblich vom Subscriber aufkommende Datenverkehr angenommen. Im ADL erfolgt die Authentifzierung sowie nach erfolgreicher Anmeldung auch die Autorisierung der Nutzer bzgl. der Zugriffe auf das SaaS Archivsystem und den darin gespeicherten Daten. Werden diese Aktionen nicht ausreichend protokolliert (durch Logging der einzelnen Aktionen und den handelnden Akteuren), ist ein Angreifer ggf. in der Lage, seine eigentliche Identität und damit fahrlässige oder auch böswillige Handlungen ( Tampering, Information Disclosure oder Denial of Service) zu verschleiern. Repudiation wird möglich durch erfolgreiches Spoofng bzw., wenn es einem Angreifer gelingt, das Logging oder Log-Protokolle zu manipulieren oder durch Manipulation zu umgehen, bspw. durch Tampering der Konfguration relevanter ADL- Komponenten. Ohne eines geeigneten und strikten Loggings kann kaum nachgewiesen werden, welcher Benutzer in der SaaS Archivsystem-Anwendung welche Tätigkeiten wann durchgeführt hat und damit für welche Daten / Datenveränderungen verantwortlich ist. Das unzureichende oder gar fehlende Logging und die ggf. nicht ausreichende mandantenspezifsche Trennung der Systeme und Anwendungen auf der Seite des CSP erleichtern es einem externen oder internen Angreifer nach erfolgreichem Spoofng unerkannt und ggf. auch unbemerkt, Daten zu manipulieren ( Tampering) oder gar zu löschen ( Denial of Service). Die Bedrohungen durch Repudiation werden auch durch die Cloud Security Alliance unter die Notorious Nine Cloud Computing Top Threats 2013 eingeordnet. Besondere Repudiation-Gefährdungen bzgl. des ADL für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Repudiation-Akteure der Subscriber End User (SEU), der Subscriber Administrator (SAD), der Cloud Service Provider Administrator (CSA), der Sub-Provider Administrator (SPA) oder auch ein Innentäter des ISP in Betracht. Dabei lassen sich vor allem folgende Einzelbedrohungsszenarien für Repudiation im Access & Delivery Layer erkennen. 1. Unsichere Authentisierung 100

101 Steckbriefe Teil 5: Eine unsichere oder auch nur unzureichende Authentisierung erleichtert Spoofng, ggf. auch Elevation of Privilege und damit die verschleierte oder bestreitbare Ausführung unzulässiger oder auch böswilliger Aktionen. Eine unsichere oder auch nur unzureichende Authentisierung erleichtert die Umgehung von Sicherheitsmaßnahmen im Zugriff auf das ADL. Eine unsichere oder auch nur unzureichende Authentisierung beteiligter Komponenten erleichtert den unbemerkten Austausch falsch oder auch böswillig konfgurierter Komponenten. 2. Unzureichende Protokollierung Eine unzureichende Protokollierung von Zugriffen erleichtert die Bestreitung fahrlässiger oder auch böswilliger Aktionen. Eine unzureichende Protokollierung und Auswertung der Protokolle erschwert die unverzügliche und angemessene Reaktion auf Sicherheitsvorfälle. 3. Unzureichender Schutz von Authentifkationsdaten Der unzureichende Schutz von Authentifkationsdaten erleichtert Spoofng und damit die Verschleierung fahrlässiger oder auch böswilliger Aktionen. 4. Unzureichender Schutz von Protokolldaten Ein unzureichender Schutz von Protokolldaten erleichtert deren Manipulation und damit die Verschleierung fahrlässiger oder böswilliger Manipulationen. Eintrittswahrscheinlichkeit gem. ALARP Schadenswirkung gem. ALARP Risikobewertung VORSTELLBAR NORMAL bis HOCH INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU-Prozesse, alle SAD-Prozesse, CSP-01, CSP-03, CSP-04 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: SEU-01, SAD-02 und SAD-03, alle Tätigkeiten von CSP-Administratoren Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, AES-01, AES-02, AES-03, AES-05, AES-06, AES-07, NCS-04, DSS-01, DSS-03, DSS-04, PKI-02, IDM-01, IDM-06, SIM-04, BCM-01, SCM-01, HRR-01, HRR-02 Restrisiken Menschliches Fehlverhalten durch ungenügende Schulung oder Sensibilisierung hinsichtlich sicherheitsrelevanter Sachverhalte der Mitarbeiter des Subscribers, des Sub-Providers, des ISP und des CSP. Konfgurationsfehler der SAD und CSP Administratoren. 101

102 Teil 5: Steckbriefe Unsicherer Umgang mit Benutzerkennungen auf der Seite des Subscribers und des Sub-Providers. Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der Vertragsparteien, sowie deren Umsetzung und Kontrolle, sollten die im Folgenden benannten Themen Gegenstand weiterer Betrachtungen sein: 102 Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung und in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: das Cloud Architekturkonzept des CSP, insbesondere bzgl. des User Portals und der Service Gateways sowie der Inter-Cloud Funktionalitäten, die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich der Gestaltung und Durchsetzung der Berechtigungs- und Rollenkonzepte, Authentifzierung und Autorisierung. Überprüfung der Logging- und der Protokollierungs-Konzepte bzgl. aller sicherheitsrelevanten Verbindungs-, System- und Nutzerereignisse, der Konzepte und Prozesse bzgl. des Monitorings dieser Log-Daten und Protokolle sowie der bei Feststellung defnierter Ereignisse vorgesehenen Maßnahmen. Überprüfung der Umsetzung und der Funktionsweise des Loggings und der Protokollierung auf den Systemen und Komponenten des Access & Delivery Layers.

103 Steckbriefe Teil 5: 5.3 Information Disclosure im Access & Delivery Layer 103

104 Teil 5: Steckbriefe Komponente Access & Delivery Layer (ADL) Das Access and Delivery Layer auf der Seite des Serviceproviders stellt Funktionen und allgemeine Infrastrukturkomponenten bereit, die dem Serviceabonnenten den Zugriff und die Nutzung des Archivsystem-Service ermöglichen. Dazu gehören sowohl Nutzerportale wie auch Servicegateways zur Steuerung und Kontrolle der Zugriffe. Da die Nutzung überwiegend über das Internet erfolgt, umfasst diese Schicht im Allgemeinen auch Netzwerkkomponenten, die in der Regel durch Netzprovider als beteiligte Dritte zur Verfügung gestellt werden. Bedrohung Information Disclosure unbefugte Kenntnisnahme Informationen Aufdeckung, Veröffentlichung von Information Disclosure im Access & Delivery Layer Information Disclosure ist hinsichtlich der zu erwartenden Risiken die wohl schwerwiegendste Bedrohungsfläche für das Access & Delivery Layer (ADL). Denn, obgleich gemäß der Defnition der IETF im ADL keine Kunden- bzw. Produktiv- oder Archivdaten vorgehalten werden sollten, befnden sich im Access & Delivery Layer Konfgurationsdaten der ADL-Komponenten und des User Portals. Diese Informationen sind, nicht nur hinsichtlich Information Disclosure, als besonders schützenswert zu defnieren. Die Kenntnis und das Wissen um diese Informationen können als Grundlage für weitere Bedrohungen und Gefährdungen dienen (bspw. Tampering oder gezieltes Information Disclosure, Repudiation, Denial of Service, Elevation of Privilege), um den Zugriff auf die Archiv-Daten in der Datenhaltungsschicht zu erlangen. Information Disclosure und Data Breaches werden durch die Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 als schwerwiegendste und wachsende Bedrohung auf Platz 1 geführt. Besondere Information Disclosure-Gefährdungen bzgl. des ADL für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Information DisclosureAkteure alle Administratoren (der Subscriber Administrator (SAD), der Cloud Service Provider Administrator (CSA), der Sub-Provider Administrator (SPA)) in Betracht, da diese auf Grund der den Administrator-Konten zugeordneten Berechtigungen das Ausmaß dieser Gefährdung auf alle Daten in der SaaS Archivsystem-Anwendung auszudehnen vermögen. Nicht auszuschließen sind auch gezielte Angriffe durch Subscriber End User (SEU) oder externe Täter, sofern es ihnen gelingt, sich mit einem erfolgreichen Spoofng-Angriff besondere Zugriffsrechte anzueignen ( Elevation of Privilege). Dabei lassen sich vor allem folgende Einzelbedrohungsszenarien für Information Disclosure im Access & Delivery Layer erkennen: 1. Einsatz von ungeeignetem, nicht sicherheitsüberprüftem Personal 104 Der Einsatz von fachlich ungeeignetem und/oder unzureichend geschultem und/oder unzureichend sicherheitsüberprüftem Personal an Schlüsselpositionen (Administration von Hard- und Softwarekomponenten oder Kommunikationsverbin-

105 Steckbriefe Teil 5: dungen) birgt ein großes Gefahrenpotential und Risiko bspw. im unsichereren Umgang mit vertraulichen, schützenswerten Archiv-Daten, und erleichtert böswillige interne Angriffe. Hinzu kommt, dass böswillige interne Angreifer ausgerüstet mit Administratorrechten viel leichter imstande sind, sich unbefugt zusätzliche Rechte anzueignen ( Elevation of Privilege) und Angriffe zu verschleiern ( Repudiation). 2. Unsichere Datenhaltungsnetzwerke und -systeme Ein Angreifer erlangt auf Grund unsicherer Datenhaltungsnetzwerke und -systeme des CSP, entweder unter Ausnutzung einer gefälschten Identität ( Spoofng) oder durch Hacking bzw. Hijacking, Kenntnis von Archivdaten ( Information Disclosure). Einem Angreifer ist es auf Grund unzureichender bzw. unsicherer Authentisierungsund Autorisierungsmaßnahmen durch Spoofng möglich, unbefugt Kenntnis von Archivdaten zu erlangen ( Information Disclosure), diese Daten zu verändern ( Tampering), oder gar zu löschen ( Denial of Service). 3. Ungeeignetes Rechte- und Rollenkonzept Auf Grund unzureichender oder unsicherer Rollen- und Berechtigungskonzepte, unzureichender Trennung von Zuständigkeiten, erlangt ein Innentäter bzw. nach erfolgreichem Spoofng auch ein externer Angreifer Nutzerberechtigungen, welche die uneingeschränkte Kenntnisnahme und Veröffentlichung von Archivdaten gestützt auf gestohlene oder gefälschte Identitäten erlauben. 4. Fehlende / unsichere Verschlüsselungsverfahren Durch fehlende bzw. unzureichende Verschlüsselungsverfahren auf der Kommunikations- und der Datenhaltungsebene (bspw. durch ungeschützte Übertragung von Authentisierungsdaten bei Klartextprotokollen) wird es Innen- wie auch Außentätern ermöglicht oder auch erleichtert, sich in den Besitz von Authentifzierungsinformationen zu bringen ( Spoofng). Ausgerüstet mit den sich daraus ergebenden Berechtigungen wird es möglich, Kenntnis von den, auf der Datenhaltungsschicht der einzelnen Layer befndlichen, ggf. sensiblen Daten zu erhalten ( Information Disclosure) und diese ggf. zu manipulieren ( Tampering). Dies betrifft insbesondere Administratoren des CSP und des Sub-Providers, da diese ggf. einen privilegierten Zugriff auf Endgeräte und Datenspeicher (das Archivsystem) im Physical Resource Layer haben. Durch fehlende bzw. unzureichende Verschlüsselungsverfahren auf der Kommunikationsebene wird es externen Angreifern erleichtert, den Datenaustausch zwischen dem Subscriber und dem CSP unentdeckt zu belauschen ( Information Disclosure). Eintrittswahrscheinlichkeit gem. ALARP Schadenswirkung gem. ALARP Risikobewertung WAHRSCHEINLICH HOCH bis SEHR HOCH INAKZEPTABEL 105

106 Teil 5: Steckbriefe Prozesse, die von dieser Bedrohung direkt betrofen sind: SEU-01, SEU-03, SEU-04, SEU-06 und auch SEU-08 (da nach einem erfolgreichen Information Disclosure diese Informationen an anderer Stelle noch vorhanden sein könnten), SAD-02 und SAD-03, CSP-01, CSP-02, CSP-04 und CSP-05 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: SEU-01, SAD-02 und SAD-03, CSP-01/2 und CSP-04, beim Datenaustausch von entfernten Systemen zur Cloud und umgekehrt sowie bei der Kommunikation aller Akteure Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, AES-01, AES-02, AES-04, AES-05, AES-06, AES-07, AES-09, AES-13, NCS-01, NCS-02, NCS-03, NCS-04, DSS-01, DSS-02, DSS-03, DSS-04, DSS-05, DSS-08, PKI-01, PKI-02, PKI-03, PKI-04, IDM-01, IDM-04, IDM-06, SIM-04, BCM-01, SCM-01, HRR-01, HRR-02 Restrisiken Es gibt keine abhörsicheren Kabel, lediglich der erforderliche Aufwand zum Abhören unterscheidet sich und es ist nur mit hohem messtechnischem Aufwand feststellbar, ob eine Kommunikationsverbindung abgehört wird. Unsicherer Umgang mit Benutzerkennungen auf der Seite des Subscribers und des Sub-Providers. Fahrlässiges sowie vorsätzlich böswilliges Verhalten auf der Seite des Subscribers, des Sub-Providers, des ISP und durch CSP- Administratoren. Nicht aufgelöste Konflikte zwischen ComplianceDatenschutzrichtlinien auf der Seite des Subscribers Sicherheitsmaßnahmen des CSP. Fehlende bzw. ungenügende Anweisungen und Schulungen bzgl. des Umgangs mit sensiblen Daten auf der Seite des Subscribers und des CSP. Technisches Versagen der für die Verschlüsselung verantwortlichen Komponenten auf der Seite des Subscribers und des CSP. Anforderungen und und den etablierten Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der Vertragsparteien, sowie deren Umsetzung und Kontrolle, sollten die im Folgenden benannten Themen Gegenstand weiterer Betrachtungen sein: Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung und in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: 106 das Cloud Architekturkonzept des CSP, insbesondere bzgl. der Kommunikationsverbindungen (bspw. durch Verbot der Nutzung von Drahtlosund Funknetzwerkverbindungen und Ausschluss der Verwendung von unsicheren Protokollen in öffentlichen Netzwerken sowie bei Speichernetzen

107 Steckbriefe Teil 5: bzgl. der Maßnahmen zum Schutz der FC-Verbindungen) und der Datenhaltung, die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, bzgl. der Maßnahmen zur Gewährleistung der Vertraulichkeit, einschließlich der Gestaltung und Durchsetzung der Berechtigungs- und Rollenkonzepte, sowie der Authentifzierungs- und Autorisierungskonzepte Sicherheitsmaßnahmen des ISP sowie die Vertrags- und SLA-Gestaltung mit dem ISP. Verschlüsselungskonzepte des Subscribers und des CSP. Monitoring von Logging und und anderen sicherheitsrelevanten Ereignissen) durch den CSP. Password-Sniffing. 107

108 Teil 5: Steckbriefe 5.4 Denial of Service in der Kommunikation Subscriber Access & Delivery Layer Externe Kommunikation Subscriber (SEU-ADL) End User towards Access & Delivery Layer Die zuverlässige und sichere Verbindung zwischen dem Subscriber und der für ihn durch den CSP bereitgestellten Cloud-Lösung im Access & Delivery Layer (ADL) ist die Grundlage für die Nutzung der entfernten Cloud-Services. Die hier betrachtete Kommunikationsverbindung SEU-ADL umfasst die Kommunikationsendpunkte (Netzwerkkomponenten) auf der Seite des Subscribers und des CSP (innerhalb der Infrastruktur des ADL). Zwischen diesen Kommunikationsendpunkten des Subscribers und CSP arbeitet in der Regel ein Internet Service Provider (ISP) mit der zur Realisierung dieser Verbindung bereitgestellten Lösung (bspw. mittels einer Leased Line oder einem MPLS-Netzwerk). Bedrohung Denial of Service Dienstverhinderung Denial of Service bzgl. der Kommunikationsverbindung SEU-ADL Denial of Service (DoS) bzgl. der Kommunikationsverbindung SEU-ADL bedeutet für die Akteure des Subscribers (SEU und SAD) immer die Nichtverfügbarkeit der durch den CSP bereitgestellten Cloud-Services. DoS ist dabei in mehrerer Hinsicht eine ernst zunehmende und mehrdimensionale Bedrohungsfläche für eine SaaS Archivsystem Lösung. Einerseits müssen für eine valide Risikobewertung sämtliche relevanten Aspekte bzgl. der Sicherheit der Netzwerkkomponenten und Kommunikationsendpunkte sowohl auf der Seite des Subscribers wie auch des CSP betrachtet werden. Andererseits sind alle infrage kommenden Aspekte bzgl. der durch den ISP bereitgestellten Kommunikationslösung von gleichrangiger Bedeutung. Hierzu zählen nicht nur Themen wie Redundanz und Hochverfügbarkeit oder der Einsatz ausreichender und bzgl. der Kommunikationsbedürfnisse geeigneter Hardware oder der Schutz und die Überwachung der involvierten Kommunikationskomponenten. Hierzu gehören auch die Details bzgl. der Vertrags- und SLA-Gestaltung für die genutzte Kommunikationslösung durch die jeweiligen Akteure (Vertragspartner). Denial of Service kann sowohl eine Folge von logischen Attacken externer Angreifer (entweder als reine DoS-Attacken oder Folge eines erfolgreichen Spoofngs) auf die relevanten Komponenten des Subscribers, CSP oder ISP sein. Denial of Service in der Kommunikation zwischen dem SEU und dem ADL kann ebenso verursacht werden durch fehlerhafte, fahrlässige Konfguration von Netzwerkgeräten oder fahrlässigem bzw. böswilligem physischen Umgang mit Netzwerkkomponenten. Darüber hinaus kann DoS auch das Ergebnis von Szenarien höherer Gewalt bzw. nicht zu erwartenden Ereignissen sein (bspw. ein Erdarbeitsgerät zerstört eine Verbindungsader des ISP oder durch Umweltereignisse sind Verteilerknoten nicht mehr in Betrieb bzw. einzelne Komponenten des ISP entlang dieser Kommunikationsverbindung weisen eine Störung / einen Defekt auf oder fallen aus anderen Gründen aus). Innentäter mit Administratorrechten sind natürlich in besonderer Weise für den Zutritt und den Zugriff auf die entsprechenden Komponenten des ADL privilegiert. Die Dienstverhinderung und der Datenverlust aufgrund von Denial of Service-Bedrohun108

109 Steckbriefe Teil 5: gen werden durch die Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 als nach wie vor häufg vorkommende Bedrohungen benannt. Besondere Denial of Service-Gefährdungen bzgl. der Kommunikationsverbindung SEU-ADL Für das Szenario SaaS Archivsystem kommen als privilegierte Denial of Service-Akteure der Subscriber Administrator (SAD), der Cloud Service Provider Administrator (CSA) oder auch Innentäter des ISP in Betracht. Für die Kommunikationsverbindung SEU-ADL lassen sich vor allem folgende Denial of Service-Einzelbedrohungsszenarien erkennen: 1. Ausfall/Störung beim ISP Ein Ausfall oder eine Störung technischer Komponenten (bspw. durch technisches Versagen, Unwetter oder Wartungsarbeiten) führt bei einer unzureichenden Redundanz der Netzinfrastruktur zwangsläufg zu einer Nichterreichbarkeit des SaaS Archivsystem-Services. Eine unzureichende Sicherung von Kommunikationswegen und -endpunkten, bspw. durch den Einsatz von IDS, IPS und kryptographischer Verfahren/Technologien, erleichtert DoS-Angriffe oder andere böswillige Störungen der Kommunikation zwischen Serviceprovider und Subscriber. Eine unzureichende Bereitstellung von Netzwerkkapazitäten (bspw. Bandbreite, Router, etc.) kann bei einem erhöhten Zugriff von Nutzern und/oder Mandanten des SaaS Archivsystem-Services zumindest zu einer partiellen Nichtverfügbarkeit des Dienstes führen. Darüber hinaus kann auch eine fehlerhafte Konfguration der Komponenten bzgl. der durch den ISP bereitgestellten Kommunikationslösung, verursacht durch unbewusst oder auch bewusst fahrlässiges Fehlverhalten seitens der Administratoren des ISP, zu Ausfällen führen. 2. Unsichere, nicht redundant gestaltete Architektur Eine unsichere (nicht ausreichend vor DoS-Attacken etc. geschützte) sowie nicht ausreichend redundant gestaltete Architektur/Infrastruktur bzgl. der durch den ISP bereitgestellten Kommunikationslösung für den Subscriber und / oder CSP führen bereits bei einem einfachen technischen Ausfall zu einer zumindest partiellen Nichterreichbarkeit des SaaS Archivsystem-Services. Darüber hinaus kann auch eine ungeeignete Leitungsführung zu einem DoS Bedrohungsszenario führen. So ist bspw. eine zweite, separate Hauseinführung als Backup bzgl. der primär genutzten Kommunikationsverbindung unzweckmäßig, wenn diese Backup-Leitung auf dem gleichen APN der Primärverbindung angeschlossen ist und keine eigene, von der Primärleitung getrennte Trassen- bzw. Wegführung aufweist, da bei Ausfall dieses Anschlusspunktes des ISP dann auch die Backup-Leitung betroffen wäre. 3. Ausfall durch nicht kommunizierte, nicht abgestimmte Prozesse Die Durchführung von Wartungsarbeiten durch den ISP, die nicht mit den die Kommunikationslösung nutzenden Akteuren abgestimmt und vereinbart worden sind, haben ggf. die Nichtverfügbarkeit der für den Subscriber entfernten Cloud-Services zur Folge. 4. Unzureichend überwachte und gesicherte Kommunikationsverbindungen Nicht bzw. unzureichend überwachte und gesicherte Kommunikationsverbindungen stellen nicht nur durch das vorhandene Abhörpotenzial eine sehr große Gefährdung dar, sondern weisen insbesondere bzgl. möglicher Manipulationen eine enorme Ge- 109

110 Teil 5: Steckbriefe fährdungsfläche auf. Hierbei ist aber nicht nur die bewusste (logische) Manipulation von Kommunikationsverbindungen durch externe Angreifer oder Innentäter zu betrachten, denn insbesondere die Zerstörung von Leitungen (Kabelstrecken wie bspw. die Primärverbindung zum ISP) und Anschlusspunkten hat weitreichende Auswirkungen bzgl. der (Nicht-) Verfügbarkeit ( Denial of Service) der vom CSP bereitgestellten SaaS Lösung. Die bewusst manipulativ herbeigeführten Fehlfunktionen von Kommunikationsverbindungen (bspw. verursacht durch falsches Patchen oder verunreinigte Steckverbindungen) führen zu einer effektiven Störung oder bei Ausfall zu einer zumindest partiellen Nichterreichbarkeit des SaaS Archivsystem-Services oder verursachen bei größerem Ausmaß bzw. steigender Häufgkeit auch zu fnanziellen Schäden. Eintrittswahrscheinlichkeit gem. ALARP GELEGENTLICH Schadenswirkung gem. ALARP HOCH Risikobewertung INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU- Prozesse, alle SAD- Prozesse, CSP-Prozesse, welche der Verbindung zu den entfernten Akteuren oder Komponenten bedürfen Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: SEU-01, SAD-02 bis SAD-03, CSP-02, CSP-04, CSP-05 Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, IFS-02, AES-04, AES-07, AES-08, AES-11, AES-12, NCS-01, NCS-02, NCS-03, NCS-04, NCS-05, DSS-03, DSS-04, DSS-07, IDM-01, UIC-01, SIM-01, SIM-04, BCM-01, BCM-02, BCM-03, BCM-04, HRR-02 Restrisiken unsichere Kommunikationsendpunkte auf der Seite des Subscribers (DoS Angriffe können sich auch gegen den Subscriber richten), unsichere oder fehlerhafte Kommunikationskomponenten, unzureichende oder fehlende Maßnahmen bzgl. Szenarien Höherer Gewalt, unzureichende Kommunikation zwischen ISP einerseits und CSP sowie Subscriber andererseits bezüglich Wartungsmaßnahmen oder Änderung von Zugangsmechanismen. Konfguration von Sicherheits- und Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der Vertragsparteien, sowie deren Umsetzung und Kontrolle, sollten die nachfolgend benann- 110

111 Steckbriefe Teil 5: ten Themenfelder Gegenstand weitergehender Untersuchungen sein: 5.5 Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: das Cloud Architekturkonzept des CSP, insbesondere hinsichtlich der Kommunikationsendpunkte im ADL, die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP und des Subscribers bzgl. Redundanz, Hochverfügbarkeit und Ausfallsicherheit der Kommunikationsverbindungen, die Vertrags- und SLA-Gestaltung mit dem ISP Disaster Recovery- und Notfallkonzepte des CSP und des ISP, Konzepte des ISP bzgl. Redundanz und Hochverfügbarkeit bzw. Ausfallsicherheit Tampering im Cloud Service Layer Komponente Cloud Service Layer (CSL) Das Cloud Service Layer als unmittelbare Laufzeitumgebung der SaaS Archivanwendung steuert den Bedarf an funktionalen virtuellen und physischen Ressourcen, die für die Ausführung des Archivsystems benötigt werden, d. h. den Ressourcentyp (CPU, Arbeitsspeicher, Festplattenspeicher usw.) die Leistungsfähigkeit und den Umfang der benötigten Ressourcen, die Art der Bereitstellung (ausschließlich reserviert für einen Abonnenten oder gemeinsam nutzbar, Transportmedien usw.), den Zeitpunkt der Bereitstellung (on-demand oder in Zeitscheiben) sowie die Dauer der Bereitstellung. In Abhängigkeit von der Orchestration der in den Service involvierten Komponenten umfasst das Cloud Service Layer ebenfalls die InterCloud Geschäfts-, Kunden-, Netzwerk- und Kommunikationsanwendungen bzw. Schnittstellen zu ggf. extern (außerhalb der Cloud) bereitgestellten Ressourcen sowie die für den Cloud Service erforderliche Middleware (bspw. für Lastverteilung, den Service Bus und das VM- Management). Bedrohung Tampering Fälschung, Manipulation von Daten 111

112 Teil 5: Steckbriefe Tampering im Cloud Service Layer Tampering stellt für das Cloud Service Layer (CSL) eine schwerwiegende Bedrohungsfläche dar, da es eine Gefährdung aller auf dem CSL befndlichen Konfgurationsdaten der in die Bereitstellung des Service involvierter Ressourcen bedeutet. Ein erfolgreicher Tampering-Angriff kann sich maßgeblich auf sämtliche in den Kommunikationsfluss im orchestrierten SaaS Archivsystem-Service involvierten Ressourcen auswirken. Damit betrifft Tampering im Cloud Service Layer nicht nur Konfgurations- und Prozessdaten involvierter Anwendungen oder Dienste, sondern auch die in den Anwendungen oder Diensten verarbeiteten und über Schnittstellen kommunizierten Archivdaten. Ausgenommen fahrlässige Handlungen, ist ein erfolgreiches Spoofng für externe wie für interne Angreifer Voraussetzung für Tampering. Dabei sind natürlich mit Administratorrechten ausgestattete Innentäter in besonderer Weise für den Zugriff auf Konfgurationsdaten des CSL privilegiert und damit mittelbar die Orchestration der für die Ausführung des SaaS Archivsystem-Service erforderlichen Ressourcen betroffen. Die Bedrohung durch Tampering wird durch die Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 grundsätzlich als eine der großen, weil kritischen Bedrohungen benannt. Besondere Tampering-Attacken bzgl. des CSL für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Tampering-Akteure der Subscriber End User (SEU) bzgl. der zu archivierenden Daten, der Subscriber Administrator (SAD) und der Cloud Service Provider Administrator (CSA) bzgl. der Konfgurationsdaten involvierter Anwendungen und Ressourcen, sowie der Sub-Provider Administrator (SPA) bzgl. der im CSL zur Verwendung kommenden und durch den Sub-Provider bereitgestellten Ressourcen in Betracht. Dabei lassen sich vor allem folgende Einzelbedrohungsszenarien für Tampering im Cloud Service Layer erkennen: 1. Datenmanipulation durch unsichere Schnittstellen 112 Unsichere Schnittstellen bedeuten in diesem Zusammenhang, dass diese unzureichend kryptographisch gesichert sind, diese nicht überwacht werden bzw. ihre auf einem Dienst basierende Funktion und die über die Schnittstelle erfolgende Kommunikation nicht selbst überwachen oder, dass diese Schnittstellen unsicher konfguriert sind (bspw. ein nicht sicheres Protokoll für die Kommunikation nutzen) oder weil diese Schnittstellen nicht im Sicherheitskonzept des CSP vorkommen, möglicherweise Daten an der Sicherheitsarchitektur vorbei direkt mit den durch sie angebundenen Anwendungen ausgetauscht werden. Sollte eine solche Schnittstelle also bspw. jeden ankommenden Datenverkehr, der das zur Kommunikation benötigte Protokoll nutzt, unkontrolliert an die dahinter betriebene Anwendung oder Datenbank mit Lese- und Schreibberechtigung weiterleiten, könnte ein potenzieller Angreifer über diese Schnittstelle manipulierte Daten nahezu unbemerkt in die dahinter befndliche Anwendung oder Datenbank einbringen. Sollte eine solche Schnittstelle den relevanten Datenverkehr zudem unverschlüsselt kommunizieren (Verschlüsselung hier bspw. via ML-Encryption), so ist es einem potentiellen Angreifer einfach möglich, schnittstellenspezifsche Anforderungen anhand einer Analyse des übermittelten Datenverkehrs festzustellen.

113 Steckbriefe Teil 5: 2. Datenmanipulation durch Hacking der CSP Architektur Ein Angreifer gelangt entweder nach erfolgreichem Spoofng oder über die unzureichend gesicherte Architektur des CSP direkt an die Datenhaltungsschichten der einzelnen Layer ( Hacking). Dadurch ist es dem Angreifer möglich, Kenntnis von Kundendaten zu erhalten ( Information Disclosure) und/oder Kundendaten zu manipulieren ( Tampering). 3. Datenmanipulation auf Grund einer ungenügenden Trennung der Mandanten Eine unsichere Trennung der Ressourcen und Daten auf der Seite des CSP ermöglicht oder erleichtert ggf. Administratoren eines Subscribers die Einsichtnahme ( Information Disclosure) und den Zugriff auf sowie die Manipulation ( Tampering) von Daten eines anderen Mandanten. 4. Datenmanipulation durch Eskalation von Zugrifsrechten Eine unzureichende Trennung von Zugriffsrechten und/oder Autorisierung beim Zugriff auf eine Managementkonsole für das CMP erleichtert Innentätern den Zugriff auf Kundendaten Elevation of Privilege. 5. Unbeabsichtigte Datenmanipulation Unbeabsichtigte Datenmanipulationen innerhalb von Speicherlösungen können die Informationssicherheit erheblich beeinträchtigen. Je umfangreichere Zugriffsberechtigungen auf Speichersysteme für die Anwender bestehen, um so größer ist auch das Risiko einer unbeabsichtigten Datenmanipulation. Dies kann prinzipiell von keiner Anwendung verhindert werden. Die grundsätzlichen Ursachen für unbeabsichtigte Datenmanipulationen können z. B. sein: mangelhafte oder fehlende Fachkenntnisse, mangelhafte oder fehlende Kenntnisse der Anwendung, zu umfangreiche Zugriffsberechtigungen und Fahrlässigkeit (z. B. das Verlassen des Arbeitsplatzes ohne korrekte Beendigung der Anwendung). Eintrittswahrscheinlichkeit gem. ALARP Schadenswirkung gem. ALARP Risikobewertung VORSTELLBAR SEHR HOCH INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU-Prozesse, SAD-01 bis SAD-03, CSP-01/2, CSP-02 bis CSP-05 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: SEU-01 und SEU-04, SAD-01, SAD-02, SAD-03/2 und SAD-03/3, CSP-01/2, CSP-03 und CSP

114 Teil 5: Steckbriefe Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, IFS-02, AES-01, AES-02, AES-04, AES-05, AES-06, AES-07, AES-09, AES-13, NCS-01, NCS-02, NCS-03, DSS-01, DSS-02, DSS-03, DSS-04, DSS-05, DSS-08, PKI-01, PKI-02, PKI-03, PKI-04, IDM-01, IDM-04, IDM-06, SIM-04, BCM-01, SCM-01, HRR-01, HRR-02 Restrisiken Unzureichende Integritätsprüfungen und Schutz transportierter (kommunizierter) Daten. Unsicherer Umgang mit Benutzerkennungen auf der Seite des Subscribers und des Sub-Providers. Fahrlässiges Fehlverhalten von mit Administratorrechten ausgestatteten Mitarbeitern des Subscribers, des Sub-Providers, des ISP und des CSP. Konfgurationsfehler im CSL, bspw. nach Wartungsarbeiten, Updates oder dem Austausch von Komponenten. Szenarien Höherer Gewalt, die zum Ausfall oder Störung des CSL führen. Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der einzelnen Akteure, sowie deren Umsetzung und Kontrolle, sollten die nachfolgend benannten Themenfelder Gegenstand weitergehender Untersuchungen sein: 114 Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: das Cloud Architekturkonzept des CSP, insbesondere bzgl. der genutzten Schnittstellen und Kommunikationsverbindungen zwischen den in die Bereitstellung des Service involvierten Ressourcen, Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich Berechtigungsund Rollenkonzepten / Authentifzierungs- und Autorisierungskonzepte auf Managementkonsolen des CSP sowie von Maßnahmen zur Umsetzung einer sicheren Kommunikation über Schnittstellen. Überprüfung der Prozesse bzgl. der Validierung und Integritätsprüfung von persistenten Daten, sowie von Daten während des Transports, einschließlich dazugehörender API und anderer Schnittstellen. Monitoring von Logging und Log-Daten sowie die Aggregation und das Monitoring sicherheitsrelevanter Ereignisse durch den CSP.

115 Steckbriefe Teil 5: 5.6 Information Disclosure im Cloud Service Layer Komponente Cloud Service Layer (CSL) Das Cloud Service Layer als unmittelbare Laufzeitumgebung der SaaS Archivanwendung steuert den Bedarf an funktionalen virtuellen und physischen Ressourcen, die für die Ausführung des Archivsystems benötigt werden, d. h. den Ressourcentyp (CPU, Arbeitsspeicher, Festplattenspeicher usw.), die Leistungsfähigkeit und den Umfang der benötigten Ressourcen, die Art der Bereitstellung (ausschließlich reserviert für einen Abonnenten oder gemeinsam nutzbar, Transportmedien usw.), den Zeitpunkt der Bereitstellung (on-demand oder in Zeitscheiben) sowie die Dauer der Bereitstellung. In Abhängigkeit von der Orchestration der in den Service involvierten Komponenten umfasst das Cloud Service Layer ebenfalls die InterCloud Geschäfts-, Kunden-, Netzwerk- und Kommunikationsanwendungen bzw. Schnittstellen zu ggf. extern (außerhalb der Cloud) bereitgestellten Ressourcen sowie die für den Cloud Service erforderliche Middleware (bspw. für Lastverteilung, den Service Bus und das VM- Management). Bedrohung Information Disclosure Aufdeckung, Veröffentlichung von Informationen Information Disclosure im Cloud Service Layer Information Disclosure stellt für das Cloud Service Layer (CSL) die größte Bedrohungsfläche dar. Gemäß dem Cloud-Stack der IETF befnden sich im CSL die durch den Subscriber genutzten Cloud-Anwendungen und Dienste sowie deren Schnittstellen zu weiteren Anwendungen, Diensten und/oder Datenbanken. Damit betrifft die Gefährdung durch Information Disclosure im CSL nicht nur Konfgurations- und Prozessdaten involvierter Anwendungen und Schnittstellen, sondern auch die in den Anwendungen verarbeiteten und über die Schnittstellen kommunizierten Kundendaten. Erfolgreiches Information Disclosure im CSL wird möglich oder erleichtert nach einem erfolgreichen Spoofng, durch privilegierte, d. h. mit Administratorrechten ausgestattete Innentäter, durch unzureichende oder unsichere Trennung von Mandanten sowie aufgrund von Konfgurationsfehlern im CSL. Information Disclosure wird durch die Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 als schwerwiegendste und zugleich Bedrohung genannt. 115

116 Teil 5: Steckbriefe Besondere Information Disclosure-Gefährdungen bzgl. des CSL für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Information DisclosureAkteure vor allem die Administratoren in Betracht, wobei der Subscriber Administrator (SAD) nur eingeschränkt Zugriff auf die Anwendungskonfgurationen im CSL und in der Regel wohl kaum Zugriff auf die Schnittstellenkonfgurationen und die Middleware des CSL haben dürfte. Ein Administrator des CSP hingegen ist entweder bereits im Besitz von umfassenden Zugriffsberechtigungen auf Anwendungen, Schnittstellen und eingesetzter Middleware oder kann sich diesen ggf. leichter beschaffen. In Frage kommt auch ein SubProvider Administrator (SPA), dem ggf. im Rahmen der Bereitstellung externer Ressourcen ein weitgehendes Zugriffsrecht auf Komponenten und Ressourcen des CSL eingeräumt wird. Letztlich können natürlich auch Information Disclosure Angriffe durch Subscriber End User (SEU) oder externe Angreifer nicht gänzlich ausgeschlossen werden, sofern sie sich nach einem erfolgreichen Spoofng in den Besitz von Administratorrechten bringen können ( Elevation of Privilege). Daher lassen sich vor allem folgende Einzelbedrohungsszenarien für Information Disclosure, zusätzlich zu den unter dem ADL aufgeführten Bedrohungen, für den Cloud Service Layer erkennen: 1. Unsicherer Datenaustausch Ein unzureichend geschützter (bspw. durch unsichere Kommunikationsprotokolle oder unzureichende Verschlüsselung) Datenaustausch zwischen den Komponenten des CSL ermöglicht oder erleichtert die unbefugte Kenntnisnahme und ggf. sogar die Manipulation von Daten ( Tampering) während des Austauschs. Dieses gilt insbesondere für Import- / Exportfunktionen, sowie Up- und Downloads von Informationen durch den Subscriber, aber auch bzgl. einer durch die Anwendungen initiierten Inter-Cloud- Kommunikation bspw. über Schnittstellen oder Netzwerk- und Middleware- Komponenten. 2. Ungenügende Mandantentrennung Vor dem Hintergrund, dass in der Cloud Datenflüsse, Anwendungen und Ressourcen unterschiedlicher Mandanten virtualisiert, d. h. nicht mehr strikt physikalisch voneinander getrennt werden, ermöglichen oder erleichtern ungeschützte oder fehlerhaft konfgurierte Firewalls, unzureichende Zugriffskontrollen, unsichere VLANs und virtualisierte Speicherressourcen die unbefugte Kenntnisnahme verarbeiteter oder gespeicherter Daten. 3. Ungeeignete Technologien Der Einsatz von im Cloud-Umfeld ungeeigneten oder unsicheren Technologien hinsichtlich der erwünschten Mandantenfähigkeit, insbesondere für sicherheitsrelevante Komponenten oder Schnittstellen, ermöglicht oder erleichtert die Nutzung von Schwachstellen für erfolgreiche Information Disclosure Angriffe. 4. Unzureichende Erfahrung / Fehlendes Sicherheitsbewusstsein 116 Unzureichend ausgebildete oder unerfahrene Administratoren erhöhen das Risiko fahrlässigen Fehlverhaltens in der Konfguration und Kombination sicherheitsrelevanter Komponenten und der Bewertung sicherheitsrelevanter Ereignisse oder

117 Steckbriefe Teil 5: Schwachstellen. Unsicheres, nicht endgültiges Löschen bzw. Überschreiben von Daten auf den zum Austausch oder für Wartungsarbeiten durch Dritte vorgesehenen CSL- Komponenten (komplette Systeme oder einzelne Datenträger) kann die unbeabsichtigte Weitergabe von ggf. sensiblen (Rest-) Informationen ( Information Disclosure) zur Folge haben. Unter Verwendung entsprechender Werkzeuge ist die Rekonstruktion und anschließende Kenntnisnahme der tatsächlichen Inhalte dieser Daten möglich, welche dann zur Vorbereitung und Durchführung von Angriffen genutzt werden können (bspw. Spoofng, Tampering oder Denial of Service). Eintrittswahrscheinlichkeit gem. ALARP Schadenswirkung gem. ALARP GELEGENTLICH HOCH bis SEHR HOCH Risikobewertung INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU-Prozesse, alle SAD-Prozesse, CSP-01/2, CSP-01/1, CSP-01/2, CSP-03 und CSP-04 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: SEU-01, SAD-02/2, SAD-02/3, SAD-03/2 und SAD-03/3 Konfgurationstätigkeiten der CSP-Administratoren im Rahmen von CSP-01/2 und CSP-04 Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, AES-01, AES-02, AES-04, AES-05, AES-06, AES-07, AES-09, AES-13, NCS-01, NCS-02, NCS-03, NCS-04, DSS-01, DSS-02, DSS-03, DSS-04, DSS-05, DSS-08, PKI-01, PKI-02, PKI-03, PKI-04, IDM-01, IDM-04, IDM-06, SIM-04, BCM-01, SCM-01, HRR-01, HRR-02 Restrisiken Unsicherer oder fahrlässiger Umgang mit Benutzerkennungen. Fahrlässiges sowie vorsätzlich böswilliges Verhalten auf der Seite des Subscribers, des Sub-Providers und durch CSP- Administratoren. Nicht aufgelöste Konflikte zwischen den Datensicherheitsanforderungen des Subscribers und Sub-Providers. Fehlende bzw. ungenügende Anweisungen und Schulungen bzgl. des Umgangs mit sensiblen Daten auf der Seite des Subscribers. Datenschutzdes Providers und bzw. Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der 117

118 Teil 5: Steckbriefe einzelnen Akteure, sowie deren Umsetzung und Kontrolle, sollten vor allem die nachfolgend benannten Themenfelder Gegenstand weitergehender Untersuchungen sein: 118 Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: das Cloud Architekturkonzept des CSP, insbesondere bzgl. der genutzten Schnittstellen und Kommunikationsverbindungen zwischen den Anwendungen und den involvierten (virtualisierten) Ressourcen, die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich der Berechtigungs- und Rollenkonzepte, Authentifzierungs- und Autorisierungskonzepte, sowie der Konzepte zur sicheren Kommunikation über Schnittstellen und einer konsequenten Mandantentrennung, einschließlich der Verschlüsselungskonzepte des Subscribers und des CSP. Monitoring von Logging- und Log-Daten sowie die Aggregation und das Monitoring sicherheitsrelevanter Ereignisse durch den CSP, Schulungsbedarf der CSP- Administratoren bzgl. der sicheren Konfguration von Mandanten-fähigen Anwendungen und deren Schnittstellen, Evaluierung von Softwareprodukten (im Rahmen der Anwendungen, Datenbanken und Schnittstellen), hinsichtlich ihrer Eignung für Mandanten-fähige Anwendungen und Services.

119 Steckbriefe Teil 5: 5.7 Tampering im Resource Control Layer Komponente Resources (RCOL) Control (Composition & Orchestration) Layer Das Resource Control (Composition & Orchestration) Layer des IETF Cloud Stack orchestriert die Bindung der über das Abstraction & Virtualization Layer virtualisierten physischen Ressourcen an mandantenbezogene Anwendungen, Konfgurationen und Daten. Die Orchestrierung beginnt mit der Anforderung eines Services, einer Anwendung oder einer Funktion im Access & Delivery Layer und endet mit der Koordination verschiedener IT-Schichten und Komponenten, die direkt oder auch indirekt in die vom Endnutzer angeforderte Leistung involviert sind. Aus sicherheitstechnischer Perspektive ist die Orchestrierung ein prozessualer Verbund von Komponenten, die in einer sicheren und zuverlässigen Art und Weise zusammenarbeiten müssen. Zu den für die Orchestrierung zu beachtenden Sicherheitsaspekten gehören: sichere Serviceübergabeschnittstellen, sichere Ressourcenbereitstellung, ein zuverlässiges Sicherheitsmonitoring der eingebundenen Ressourcen zur Laufzeit, so dass ein verdächtiges oder auch auffälliges Verhalten nicht unentdeckt bleibt. Das Resource Control Layer koordiniert und verbindet je verschiedene Schichten von Anwendungen, Netzen, virtuellen Maschinen und Hypervisoren, Betriebssystemen und Speicherbereichen und ist deshalb aus sicherheitstechnischem Blickwinkel ein besonders kritischer Bereich. Bedrohung Tampering Fälschung, Manipulation von Daten Tampering im Resource Control Layer Aufgrund der Tatsache, dass das Resources Control Layer (RCOL) die Bindung und Koordination der (virtualisierten, gleichwohl aber physikalisch mehreren Mandanten gleichzeitig bereitgestellten) Ressourcen im Cloud Computing übernimmt, stellt Tampering stellt für das Resource Control Layer (RCOL) eine schwerwiegende Bedrohungsfläche dar. Begünstigt wird dies vor allem durch die zunehmende Komplexität der Verwaltung und des Betriebs von virtualisierten Multi-Mandanten-Umgebungen mit dynamischem Ressourcenbedarf und -konsum für die Verarbeitung und Speicherung von Kundendaten. Tampering im RCOL bedeutet vor allem die Gefährdung aller im RCOL befndlichen Konfgurationsdaten (bspw. von FC Switches oder HBA's) und damit die Gefährdung der Bereitstellung des Archiving Services. Ein erfolgreicher Tampering-Angriff wirkt sich maßgeblich auf sämtliche in den Kommunikationsfluss im orchestrierten SaaS Archivsystem-Service involvierten Ressourcen aus. Damit betrifft Tampering im Resource Control Layer nicht nur Konfgurationsdaten involvierter Dienste oder Komponenten, sondern auch die in den Anwendungen oder Diensten verarbeiteten und über Schnittstellen kommunizierten Kundenund Archivdaten. 119

120 Teil 5: Steckbriefe Ausgenommen fahrlässige Handlungen, ist ein erfolgreiches Spoofng für externe wie für interne Angreifer Voraussetzung für Tampering. Dabei sind natürlich mit Administratorrechten ausgestattete Innentäter in besonderer Weise für den Zugriff auf Konfgurationsdaten des RCOL privilegiert und damit mittelbar die Orchestration der für die Ausführung des SaaS Archivsystem-Service erforderlichen Ressourcen betroffen. Die Bedrohung durch Tampering wird durch die Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 grundsätzlich als eine der großen, weil kritischen Bedrohungen benannt. Besondere Tampering-Gefährdungen bzgl. des RCOL für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Tampering-Akteure vor allem die Administratoren des CSP und des CSP Sub-Providers in Betracht. Für den Subscriber Administrator sowie für externe Angreifer ist ein erfolgreiches Spoofng über mehrere Schichten und Sicherheitssysteme hinweg die Voraussetzung für den Zugriff auf die Konfgurationsdaten virtueller Ressourcen im RCOL. Zusätzlich zu den unter dem ADL aufgeführten Tampering Bedrohungen lassen sich, abhängig natürlich von jeweiligen Architektur-, Sicherheits- und Betriebskonzepten, sowie deren Umsetzung, für das Szenario SaaS Archivsystem folgende Einzelbedrohungsszenarien für Tampering im Resources Control Layer erkennen: 1. Veränderung der Konfgurationsdaten Ein Angreifer erhält nach einer erfolgreichen Spoofng-Attacke Zugriff auf Konfgurationsdaten derrcol-komponenten oder Dienste. Er ist in der Folge in der Lage, mit einer Veränderung (Manipulation) von Konfgurationsdaten nachfolgendes Spoofng zu erleichtern, und damit auch ein erneutes, ggf. auch wirkungsvolleres Tampering (gestützt auf Elevation of Privilege mit ggf. nachfolgendem Information Disclosure) durchzuführen, aber auch die korrekte Ausführung bzw. die Verfügbarkeit des Service insgesamt zu beeinträchtigen ( Denial of Service). 2. Datenmanipulation durch Hacking der RCOL Architektur Ein Angreifer gelangt entweder nach erfolgreichem Spoofng oder über die unzureichend gesicherte Architektur des CSP direkt an die Datenhaltungsschichten der einzelnen Layer ( Hacking). Dadurch ist es dem Angreifer möglich, Kenntnis von Kundendaten zu erhalten ( Information Disclosure) und/oder Kundendaten zu manipulieren ( Tampering). 3. Datenmanipulation auf Grund einer ungenügenden Trennung der Mandanten Eine unsichere Trennung der Ressourcen und Daten auf der Seite des CSP ermöglicht oder erleichtert ggf. Administratoren eines Subscribers die Einsichtnahme ( Information Disclosure) und den Zugriff auf sowie die Manipulation ( Tampering) von Daten eines anderen Mandanten. 4. Unbeabsichtigte Datenmanipulation 120 Unbeabsichtigte Datenmanipulationen innerhalb von Speicherlösungen können die

121 Steckbriefe Teil 5: Informationssicherheit erheblich beeinträchtigen. Je umfangreichere Zugriffsberechtigungen auf eine Datenbank für die Anwender bestehen, um so größer ist auch das Risiko einer unbeabsichtigten Datenmanipulation. Dies kann prinzipiell von keiner Anwendung verhindert werden. Die grundsätzlichen Ursachen für unbeabsichtigte Datenmanipulationen können z. B. sein: mangelhafte oder fehlende Fachkenntnisse, mangelhafte oder fehlende Kenntnisse der Anwendung, zu umfangreiche Zugriffsberechtigungen und Fahrlässigkeit (z. B. das Verlassen des Arbeitsplatzes ohne korrekte Beendigung der Anwendung). 5. Datenmanipulation durch nicht kommunizierte, nicht abgestimmte Prozesse Im weitesten Sinne kann auch eine nicht mit dem Subscriber verabredete Datenwiederherstellung (im Rahmen von Backup- und Recovery- Verfahren) durch den CSP den Anschein des Tampering erwecken, denn dadurch erscheint dem SEU beim nächsten Login ein alter und im ersten Moment veränderter Datenbestand. Eintrittswahrscheinlichkeit gem. ALARP VORSTELLBAR Schadenswirkung gem. ALARP Risikobewertung SEHR HOCH INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: SEU-03 bis SEU-08, SAD-01, SAD-02/3 und SAD-03/3, CSP-01/1, CSP-01/2 und CSP-04 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: CSP-01/1, CSP-01/2, CSP-04/2, CSP-04/4 und CSP-04/5 Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, IFS-02, AES-01, AES-02, AES-04, AES-05, AES-06, AES-07, AES-09, AES-13, NCS-01, NCS-02, NCS-03, DSS-01, DSS-02, DSS-03, DSS-04, DSS-05, DSS-08, PKI-01, PKI-02, PKI-03, PKI-04, IDM-01, IDM-04, IDM-06, SIM-04, BCM-01, SCM-01, HRR-01, HRR-02 Restrisiken Unzureichende oder fehlende Maßnahmen bzgl. Szenarien Höherer Gewalt. Unzureichende Kommunikation zwischen CSP und Subscriber Wartungsmaßnahmen oder Änderung von Zugangsmechanismen. Fahrlässiges Verhalten der Administratoren des CSP und des Subproviders hervorgerufen durch fehlende bzw. ungenügende Anweisungen und Schulungen bzgl. des Umgangs mit sensiblen Konfgurationsdaten des RCOL. Vorsätzlich böswilliges Verhalten auf der Seite des Sub-Providers und durch die bezüglich 121

122 Teil 5: Steckbriefe CSP- Administratoren. Nicht aufgelöste Konflikte zwischen den Datensicherheitsanforderungen der Vertragsparteien. Datenschutz- und Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der einzelnen Akteure, sowie deren Umsetzung und Kontrolle, sollten die nachfolgend aufgeführten Themenfelder weiter untersucht werden: 122 Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: das Cloud Architekturkonzept des CSP, insbesondere bzgl. der Infrastruktur und des Betriebs der Speichersysteme und Speichernetze (Storage Konzept), Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich der Berechtigungs- und Rollenkonzepte sowie auch die Disaster Recovery- / Notfallkonzepte und das Storage Security Konzepts des CSP und des Subcribers, Vertrags- und SLA-Gestaltung zwischen Subscriber und CSP. Konzepte zur Storage Virtualisierung (Einsatz von Disk-Sub-Systemen oder Virtualisierung von SAN, Zoming und LUN Maskierung), bspw. Block- und File-orientierte Virtualisierung (dem Betriebssystem zur Verfügung gestellte, virtuelle Festplatten, die von einer außerhalb der Serverebene liegenden Schicht verwaltet werden), In-Band Virtualisierung (symmetrische Virtualisierung), Out of Band Virtualisierung (asymmetrische Virtualisierung). Server- Virtualisierungskonzepte. Verwaltung, Administration und Monitoring von virtualisierten Komponenten und Speichernetzen, mittels In-Band-Management (die Administration der Netzwerkgeräte aus dem Nutzwerk selbst heraus, meistens via eines Management-Agent, welcher sowohl mit dem LAN als auch mit dem SAN verbunden ist) SNMP (für das Simple Network Management Protocol wurden im Bereich der Speichergeräte zwei Geräteklassen-MIBs verabschiedet: die Fabric Element MIB (defniert von SNIA) und die Fibre-Channel MIB (defniert von Fibre Alliance), um ein Mindestmaß an Interoperabilität zu gewährleisten, jedoch verwendet SNMP bzgl. der Zustellung von Nachrichten das unsichere UDP und die Nutzung von SNMP- Agents gilt ebenfalls als unsicher), Out-Band-Management (Administration mittels Kombination der Ethernet-Schnittstelle, welche nahezu jedes Speichergerät in einem SAN aufweist, mit bereits bestehenden Standards zur Systempflege und -über-

123 Steckbriefe Teil 5: wachung). Verschlüsselungskonzepte des Subscribers und des CSP, für die Sicherung von Daten in flexibel agierenden Speichernetzen. Erfahrung der CSP- und der Sub-Provider Administratoren bzgl. der sicheren Konfguration von virtuellen Umgebungen, Speicherplatzverwaltung (SAN Masking und Zoning, Verwaltung von LUN), einschließlich der ggf. auf diese zugreifenden Datensicherungs- und Backupsysteme. Sicherstellung der SAN-Segmentierung durch die sichere Zuordnung von SAN-Ressourcen (bspw. durch die Regelung der Segmentierung bei FC-SAN's und/oder ISCSI, Festlegungen zum Soft und Hard Zoning, LUN Binding und Masking, VSAN's) in Anlehnung an BSI IT-Grundschutz Maßnahme

124 Teil 5: Steckbriefe 5.8 Information Disclosure im Resource Control Layer Komponente Resources (RCOL) Control (Composition & Orchestration) Layer Das Resource Control (Composition & Orchestration) Layer des IETF Cloud Stack orchestriert die Bindung der über das Abstraction & Virtualization Layer virtualisierten physischen Ressourcen an mandantenbezogene Anwendungen, Konfgurationen und Daten. Die Orchestrierung beginnt mit der Anforderung eines Services, einer Anwendung oder einer Funktion im Access & Delivery Layer und endet mit der Koordination verschiedener IT-Schichten und Komponenten, die direkt oder auch indirekt in die vom Endnutzer angeforderte Leistung involviert sind. Aus sicherheitstechnischer Perspektive ist die Orchestrierung ein prozessualer Verbund von Komponenten, die in einer sicheren und zuverlässigen Art und Weise zusammenarbeiten müssen. Zu den für die Orchestrierung zu beachtenden Sicherheitsaspekten gehören: sichere Serviceübergabeschnittstellen, sichere Ressourcenbereitstellung, ein zuverlässiges Sicherheitsmonitoring der eingebundenen Ressourcen zur Laufzeit, so dass ein verdächtiges oder auch auffälliges Verhalten nicht unentdeckt bleibt. Das Resource Control Layer koordiniert und verbindet je verschiedene Schichten von Anwendungen, Netzen, virtuellen Maschinen und Hypervisoren, Betriebssystemen und Speicherbereichen und ist deshalb aus sicherheitstechnischem Blickwinkel ein besonders kritischer Bereich. Bedrohung Information Disclosure Aufdeckung, Veröffentlichung von Informationen Information Disclosure im Resources Control Layer Aufgrund der Tatsache, dass das Resources Control Layer (ROCL) die Bindung und Koordination der (virtualisierten, gleichwohl aber physikalisch mehreren Mandanten bereitgestellten) Ressourcen im Cloud Computing übernimmt, ist das ROCL ein lukratives Ziel sowohl für Information Disclosure wie auch Denial of Service. Von Information Disclosure bedroht sind im ROCL vornehmlich Konfgurationsdaten (von FC Switches oder HBA's ), weil durch sie die Segmentierung der (virtuellen) Ressourcen maßgeblich bestimmt und über ihre Kenntnisnahme ein direkter Zugriff auf Kundendaten möglich wird. Im Kontext vernetzter Datenspeicher bspw. genügt der Snapshot eines SANs, um Kenntnis einer LUN oder LUN-Gruppe und damit die Adresse gespeicherter Daten zu erhalten. Werden Daten darüber hinaus Standort-übergreifend transferiert (Replikation oder Spiegelung) ist ein Information Disclosure im Falle einer ungenügenden kryptographischen Sicherung auch durch ein einfaches Eavesdropping möglich. Innentäter mit Administratorrechten sind in besonderer Weise für den fahrlässigen oder böswilligen Zugriff auf die Daten und Ressourcen des RCOL privilegiert. 124

125 Steckbriefe Teil 5: Information Disclosure stellt seitens der Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 die schwer wiegendste und eine stark zunehmende Bedrohung dar. Information Disclosure im RCOL wird in der Regel neben Spoofng vor allem von Tampering und Elevation of Privilege begleitet. Besondere Information Disclosure-Gefährdungen bzgl. des RCOL für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Information DisclosureAkteure vor allem die Administratoren des CSP und des CSP Sub-Providers in Betracht. Für den Subscriber Administrator sowie externe Angreifer ist ein erfolgreiches Spoofng mehrere Schichten und Sicherheitssysteme hinweg Voraussetzung für den Zugriff auf die Konfgurationsdaten virtueller Ressourcen im RCOL. Zusätzlich zu den unter dem ADL aufgeführten Information Disclosure Bedrohungen lassen sich, abhängig natürlich von jeweiligen Architektur-, Sicherheits- und Betriebskonzepten, sowie deren Umsetzung, für das Szenario SaaS Archivsystem folgende Information Disclosure-Einzelbedrohungsszenarien für das Resources Control Layer erkennen: 1. Fehlendes Sicherheitsbewusstsein Der ggf. wirtschaftlich begründete Einsatz ungeeigneter bzw. unsicherer Segmentierunginstrumente (bspw. Soft- statt Hardware-Zoning) erleichtert Angreifern den Zugriff auf ( Information Disclosure) und die Maniplulation ( Tampering) von logisch segmentierten Ressourcen. Eine unzureichende Trennung von Zuständigkeiten (Separation of Duties) ermöglicht Angreifen über ein erfolgreiches Elevation of Privilege den unzulässigen Zugriff auf Konfgurationsdaten des RCOL. 2. Unsichere oder fehlerhafte Konfguration der Segmentierung Der Einsatz Software-basierter Segmentierung (World Wide Number / WWN Zoning) von Geräten und Ports im SAN erleichtert Angreifern das Spoofng der WWN und damit den Zugriff auf Geräte in anderen Segmenten. Da die Zugriffsberechtigung zu einem konfgurierten Ressourcensegment beim Einsatz Software-basierter Segmentierung (World Wide Number / WWN Zoning) nicht auf Hardwareniveau validiert wird, ist es für kompromittierte HBAs (Host Bus Adapter) möglich den Namensserver zu umgehen, und direkt mit einer Ressource zu kommunizieren, die nicht im konfgurierten (zugelassenen) Segment liegt. Die fehlerhafte Konfguration (LUN Maskierung) von WWN auf HBA-Level erleichtert einem Angreifer das Spoofng von LUN Gruppen und den Zugriff auf andere Segmente durch Kompromittierung des HBA. 3. Fehlendes bzw. ungenügendes Storage Security Konzept Durch fehlende oder ungenügende Sicherheitsmaßnahmen (Verschlüsselung), für gespeicherte (data-at-rest) und bewegte (data-in-transit) Daten ist es einem Angreifer möglich die Administration von virtualisierten Ressourcen im Netz (in-bandmangement) zu kompromittieren, und auf diese Weise die Konfguration von Netzgeräten oder bewegter Kundendaten zu belauschen ( Eavesdropping). 125

126 Teil 5: Steckbriefe 4. Unsichere / nicht kontrollierte Kommunikationsverbindungen Die unsichere und / oder nicht kontrollierte Kommunikation von und zu Speichersystemen (bspw. im Rahmen von Fernwartungs- und Support-Maßnahmen durch CSP Sub-Provider oder gar direkt durch die Hersteller dieser Systeme) ermöglicht die Kenntnisnahme von ggf. sensiblen Informationen durch Dritte, als ggf. auch die unverschlüsselte Übertragung von schützenswerten Daten (bspw. komplette Konfgurationsdateien). Somit ist entweder durch den unkontrolliert direkten Zugriff auf diese Systeme und Informationen Information Disclosure möglich oder aufgrund der unverschlüsselten Kommunikation das Abhören und die ggf. anschließende Verwendung dieser Daten. Insbesondere die von den (Speicher-) Systemen zum Teil automatisch erfolgenden Statusberichte (bspw. zum Abgleich ggf. verfügbarer Updates oder zur Ermittlung von Problemlösungen bzgl. aufgetretener Störungen) müssen durch den CSP kontrolliert und ggf. unterbunden werden, damit keine Rückschlüsse auf die eingesetzte Lösung durch Dritte ermittelt werden können. 5. Unzureichende / fehlerhafte Zuordnung von SAN-Ressourcen Die nicht eindeutige Zuordnung von Servern und Speicherressourcen ermöglicht unautorisierte Zugriffe ( Information Disclosure) auf dieses bspw. auf Betriebssystem- oder Anwendungsebene (bspw. versuchen manche Betriebssysteme, sich mit allen erreichbaren/ sichtbaren Festplatten zu verbinden und die Konfguration dieser Hardware zu ermöglichen). Insbesondere durch Fehlkonfguration des LUN-Maskings bzw. Mappings ist eine fehlerhafte Zuordnung von Speicherressourcen möglich. Dadurch können ggf. Speichersegmente (LUN's) an hierfür nicht vorgesehene, demzufolge unberechtigte Serversysteme zugeordnet werden. Unzureichende Regelungen des Zonings (also welche Systeme auf welche Speicherressourcen und welche Zonen zugreifen dürfen) können ebenfalls den unberechtigten Zugriff auf Speicherressourcen in Folge der fehlerhaften Zuordnungen zum Ergebnis haben. Eintrittswahrscheinlichkeit gem. ALARP GELEGENTLICH Schadenswirkung gem. ALARP SEHR HOCH Risikobewertung INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: SEU-03 bis SEU-08, SAD-01, SAD-02/3 und SAD-03/3, CSP-01/1, CSP-01/2 und CSP-04 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: CSP-01/1, CSP-01/2, CSP-04/2, CSP-04/4 und CSP-04/5 Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: 126

127 Steckbriefe Teil 5: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, AES-01, AES-02, AES-04, AES-05, AES-06, AES-07, AES-09, AES-13, NCS-01, NCS-02, NCS-03, NCS-04, DSS-01, DSS-02, DSS-03, DSS-04, DSS-05, DSS-08, PKI-01, PKI-02, PKI-03, PKI-04, IDM-01, IDM-04, IDM-06, SIM-04, BCM-01, SCM-01, HRR-01, HRR-02 Restrisiken Fahrlässiges Verhalten der Administratoren des CSP und des Subproviders hervorgerufen durch fehlende bzw. ungenügende Anweisungen und Schulungen bzgl. des Umgangs mit sensiblen Konfgurationsdaten des RCOL. Vorsätzlich böswilliges Verhalten auf der Seite des Sub-Providers und durch die CSP-Administratoren. Nicht aufgelöste Konflikte zwischen den Datensicherheitsanforderungen der Vertragsparteien. Datenschutz- und Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der einzelnen Akteure, sowie deren Umsetzung und Kontrolle, lassen sich die noch genauer zu betrachtenden Bereiche wie folgt priorisieren: Überprüfung und ggf. Anpassung der Konzepte und Richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risikound Bedrohungslage durch, d. h.: das Cloud Architekturkonzept des CSP, insbesondere die Speichersystemen und/oder Speichernetzen (DAS, NAS, SAN), Konzepte zur Storage Virtualisierung (Einsatz von Disk-Sub-Systemen oder Virtualisierung von SAN, Zoning und LUN Maskierung), bspw. Anbindung von Block- und File-orientierte Virtualisierung (dem Betriebssystem zur Verfügung gestellte, virtuelle Festplatten, die von einer außerhalb der Serverebene liegenden Schicht verwaltet werden), In-Band Virtualisierung (symmetrische Virtualisierung), Out of Band Virtualisierung (asymmetrische Virtualisierung), Server-Virtualisierungskonzepte, die Integration der Speichernetze (bspw. SAN und Sub-Systeme) in die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers hier insbesondere, Storage Security als Bestandteil der unternehmensweiten Strategie für Datenschutz und Disaster Recovery, Umgang mit schützenswerten Daten in einem (virtualisierten) SAN / RAID- System wie bspw. WWN und LUN Masken für Geräte und Ports Abspaltung eines Spiegels (mit dem Kopierbefehl werden beide Spiegel getrennt, wobei der abgetrennte Spiegel dann unabhängig vom Original benutzt werden kann) Kopieren im Nachhinein (vor dem Kopierbefehl werden in diesem Fall überhaupt keine Daten (kopiert), sondern erst nachdem die Instant Copy angefordert wird, weshalb der Controller dann zwei Datenbereiche zu 127

128 Teil 5: Steckbriefe verwalten hat: einen für die Originaldaten und einen für die mittels Instant Copy erstellte Datenkopie) 128 Snapshots (im SAN - Umfeld eine sofortige, momentane, virtuelle Kopie einer LUN bzw. einer LUN-Gruppe innerhalb eines Storage Systems, wobei sowohl die virtuelle Kopie, als auch das Original von zwei verschiedenen Hosts lesend, als auch schreibend für den Zugriff genutzt werden kann), Remote Mirroring oder Remote Replication (die redundante, physisch getrennte Auslegung von Disk-Sub-Systemen, in Abhängigkeit vom Zeitpunkt der Replikation unterscheidet man zwischen synchronem und asynchronem Remote Mirroring) Disaster Recovery bzw. Failover- Konzepte, (Daten-) Migrationskonzept des CSP (bspw. mittels Migrationsszenarien ohne Virtualisierung, wie hostbasierende Spiegelungen, Backup und Restore oder inkrementelle Kopien), Verwaltung, Administration und Monitoring von virtualisierten Komponenten und Speichernetzen, mittels In-Band-Management (die Administration der Netzwerkgeräte aus dem Nutzwerk selbst heraus, meistens via eines Management-Agents, welcher sowohl mit dem LAN als auch mit dem SAN verbunden ist) SNMP (für das Simple Network Management Protocol wurden im Bereich der Speichergeräte zwei Geräteklassen-MIBs verabschiedet: die Fabric Element MIB (defniert von SNIA) und die Fibre-Channel MIB (defniert von Fibre Alliance), um ein Mindestmaß an Interoperabilität zu gewährleisten, jedoch verwendet SNMP bzgl. der Zustellung von Nachrichten das unsichere UDP und die Nutzung von SNMP- Agents gilt ebenfalls als unsicher), Out-Band-Management (Administration mittels Kombination der Ethernet-Schnittstelle, welche nahezu jedes Speichergerät in einem SAN aufweist, mit bereits bestehenden Standards zur Systempflege und -überwachung). Verschlüsselungskonzept des Subscribers und des CSP, welches die Sicherung von Daten in flexibel agierenden Speichernetzen (bspw. durch eine Dateiverschlüsselung) beinhaltet. Erfahrung der CSP- und der Sub-Provider Administratoren bzgl. der sicheren Konfguration von virtuellen Umgebungen, Speicherplatzverwaltung (SAN Masking und Zoning, Verwaltung von LUN), einschließlich der ggf. auf diese zugreifenden Datensicherungs- und Backupsysteme. Evaluierung von Hard- und Softwareprodukten, mit denen eine separate Behandlung von unterschiedlichen Speicherbereichen in einem oder mehreren Speichernetzen verlässlich gewährleistet werden kann. Evaluierung von Fibre Channel Security Protokollen und der Empfehlungen der Technical Work Group der Storage Networking Industry Association (SNIA).

129 Steckbriefe Teil 5: Sicherstellung der SAN-Segmentierung durch die sichere Zuordnung von SAN-Ressourcen (bspw. durch die Regelung der Segmentierung bei FC-SAN's und/oder ISCSI, Festlegungen zum Soft und Hard Zoning, LUN Binding und Masking, VSAN's) in Anlehnung an BSI IT-Grundschutz Maßnahme

130 Teil 5: Steckbriefe 5.9 Denial of Service im Resource Control Layer Komponente Resources (RCOL) Control (Composition & Orchestration) Layer Das Resource Control (Composition & Orchestration) Layer des IETF Cloud Stack orchestriert die Bindung der über das Abstraction & Virtualization Layer virtualisierten physischen Ressourcen an mandantenbezogene Anwendungen, Konfgurationen und Daten. Die Orchestrierung beginnt mit der Anforderung eines Services, einer Anwendung oder einer Funktion im Access & Delivery Layer und endet mit der Koordination verschiedener IT-Schichten und Komponenten, die direkt oder auch indirekt in die vom Endnutzer angeforderte Leistung involviert sind. Aus sicherheitstechnischer Perspektive ist die Orchestrierung ein prozessualer Verbund von Komponenten, die in einer sicheren und zuverlässigen Art und Weise zusammenarbeiten müssen. Zu den für die Orchestrierung zu beachtenden Sicherheitsaspekten gehören: sichere Serviceübergabeschnittstellen, sichere Ressourcenbereitstellung, ein zuverlässiges Sicherheitsmonitoring der eingebundenen Ressourcen zur Laufzeit, so dass ein verdächtiges oder auch auffälliges Verhalten nicht unentdeckt bleibt. Das Resource Control Layer koordiniert und verbindet je verschiedene Schichten von Anwendungen, Netzen, virtuellen Maschinen und Hypervisoren, Betriebssystemen und Speicherbereichen und ist deshalb aus sicherheitstechnischem Blickwinkel ein besonders kritischer Bereich. Bedrohung Denial of Service Dienstverhinderung Denial of Service im Resources Control Layer Aufgrund der Tatsache, dass das Resources Control Layer (RCOL) die Bindung und Koordination der (virtualisierten, gleichwohl aber physikalisch mehreren Mandanten gleichzeitig bereitgestellten) Ressourcen im Cloud Computing übernimmt, ist das ROCL eine durch Denial of Service stark bedrohte Schicht. Begünstigt wird dies vor allem durch die zunehmende Komplexität der Verwaltung und des Betriebs von virtualisierten Multi-Mandanten-Umgebungen mit dynamischen Ressourcenbedarf und -konsum für die Verarbeitung und Speicherung von Kundendaten. Insbesondere aufgrund von Interoperabilitätsproblemen von Speichersystemen und angeschlossenen Sub-Systemen unterschiedlicher Anbieter, sind bspw. viele Arrays und Switche "Inseln" und müssen als solche individuell administriert und überwacht werden, da es hierfür kaum hersteller- und plattformunabhängige bzw. -übergreifende Managementwerkzeuge gibt. Dies hat zur Folge, dass die Konfguration von Aspekten wie Hochverfügbarkeit und Failover bei der Anbindung von Speicher- Host Systemen nicht immer sicher und vollautomatisch gewährleistet werden kann. 130

131 Steckbriefe Teil 5: Somit speist sich die Bedrohungsfläche Denial of Service für das RCOL aus wenigstens zwei Quellen: einerseits aus der Herausforderung komplexe und heterogene Infrastrukturen betriebswirtschaftlich sinnvoll betreiben zu können, sowie andererseits aus der Tatsache, dass gerade Cloud Infrastrukturen lukrative Ziele externer wie auch interner Angriffe sind. Folglich geht es dabei nicht nur um Denial of Service auf Grund von Fehlkonfguration bzw. Fehlverhalten durch Innentäter oder logischer Attacken durch externe Angreifer (entweder als reine DoS-Attacken oder Folge eines erfolgreichen Spoofngs). Relevant sind in diesem Zusammenhang auch die Fähigkeit der dynamisch skalierbaren Bereitstellung ausreichender Ressourcen sowie Bedrohungen durch fahrlässige oder auch böswillige physische Zugriffe auf involvierte Komponenten. Innentäter mit Administratorrechten sind in besonderer Weise für den fahrlässigen oder böswilligen Zugriff auf die Ressourcen des RCOL privilegiert. Die Dienstverhinderung und der Datenverlust auf Grund von Denial of Service-Bedrohungen sind auch seitens der Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 als häufge und wachsende Bedrohungen benannt. Besondere Denial of Service-Gefährdungen bzgl. des RCOL für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Denial of Service-Akteure der Cloud Service Provider Administrator (CSA) und der Sub-Provider Administrator (SPA) in Betracht. Dabei lassen sich zusätzlich zu den unter dem ADL aufgeführten Bedrohungen vor allem folgende Einzelbedrohungsszenarien für Denial of Service im Resource Control Layer erkennen: 1. Unzureichendes oder fehlendes Archivsystemkonzept Unter dem Archivsystemkonzept sind alle bzgl. der Planung, Beschaffung und dem Betrieb der SaaS Archivanwendung zu verstehenden Belange gemeint. Dieses Konzept muss daher Aussagen und Regelungen bzgl. der Dimensionierung der Archivsystemspeicherkapazitäten sowie bzgl. der Anforderungen an die Verfügbarkeit und benötigte Performance aufweisen, um sich daraus ergebende Betriebsarten und Dienstleistungen (welche dann in OLA's oder in SLA's münden) für die SaaS Archivanwendung festzulegen. Denn fehlen diese Regelungen, so können bereits kleine Störungen im Betrieb zu einem weitreichendem Denial of Service führen, da dann bspw. die erforderlichen Zuständigkeiten bzgl. der Behebung einer Systemstörung nicht eindeutig gegeben sind. 2. Ausfall/Störung durch den Einsatz inkompatibler Hardware Speichersysteme und daran anzuschließende Sub-Systeme, welche nicht vom gleichen Anbieter stammen, sind u. U. inkompatibel oder unterstützen keine automatischen HA oder Failover- Szenarien. Erschwerend kommt hinzu, dass es für heterogene Umgebungen nur wenige herstellerunabhängige bzw. plattformübergreifende Managementwerkzeuge gibt und somit eine effiziente Kontrolle und Überwachung dieser Komponenten fast nicht möglich ist. 3. Ausfall durch den Verlust von Daten Auf Grund eines unzureichenden oder gar fehlenden Archivsystemkonzepts, einschließlich eines zugehörigen, adäquaten Sicherheitskonzeptes, können folgende Szenarien den Verlust gespeicherter Informationen und damit einen Denial of Service zur Folge haben: 131

132 Teil 5: Steckbriefe Der Ausfall von Hardware (bspw. verursacht durch Schadprogramme, fehlerhafte Datenträger oder Szenarien höherer Gewalt). Der unzureichende Schutz vor Schadprogrammen. Durch Fehlkonfgurationen (bspw. auf Grund von fahrlässigem Fehlverhalten bzw. böswilligem Verhalten) erfolgendes Überschreiben bzw. Löschen. Eine unsichere oder fehlerhafte LUN Maskierung. Die Kompromittierung von HBA's erleichtert das Spoofng von WWN und damit den Zugriff auf andere Segmente Information Disclosure sowie die Löschung von Daten, mit dem Ergebnis eines Denial of Service. Eintrittswahrscheinlichkeit gem. ALARP VORSTELLBAR Schadenswirkung gem. ALARP HOCH Risikobewertung INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU- Prozesse, SAD-01, SAD-02/3 und SAD-03/3, CSP-01/1, CSP-01/2 und CSP-04 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: alle Anmeldungen und bei den Konfgurationstätigkeiten der CSP- und der Sub-Provider Administratoren Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, IFS-02, AES-04, AES-07, AES-08, AES-11, AES-12, NCS-01, NCS-02, NCS-03, NCS-04, NCS-05, DSS-03, DSS-04, DSS-07, IDM-01, UIC-01, SIM-01, SIM-04, BCM-01, BCM-02, BCM-03, BCM-04, HRR-02 Restrisiken Unzureichende Schulung von Mitarbeitern beim CSP und Sub-Provider. Unsichere oder fehlerhafte Konfguration von Speicherkomponenten. Unzureichende oder fehlende Maßnahmen bzgl. Szenarien Höherer Gewalt. Unzureichende Kommunikation zwischen CSP und Subscriber Wartungsmaßnahmen oder Änderung von Zugangsmechanismen. bezüglich Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der Vertragsparteien, sowie deren Umsetzung und Kontrolle, sollten die nachfolgend benannten Themenfelder Gegenstand weitergehender Untersuchungen sein: 132 Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell

133 Steckbriefe Teil 5: gegebene Risiko- und Bedrohungslage, d. h.: das Cloud Architekturkonzept des CSP, insbesondere bzgl. der Infrastruktur und des Betriebs der Speichersysteme und Speichernetze (Storage Konzept), Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich der Berechtigungs- und Rollenkonzepte, sowie auch die Disaster Recovery- / Notfallkonzepte und das Storage Security Konzepts des CSP und des Subcribers, Vertrags- und SLA-Gestaltung zwischen Subscriber und CSP, Konzepte des CSP bzgl. des Einsatzes Host-basierter IDS- und IPS- Systeme. 133

134 Teil 5: Steckbriefe 5.10 Elevation of Privilege im Resource Control Layer Komponente Resources (RCOL) Control (Composition & Orchestration) Layer Das Resource Control (Composition & Orchestration) Layer des IETF Cloud Stack orchestriert die Bindung der über das Abstraction & Virtualization Layer virtualisierten physischen Ressourcen an mandantenbezogene Anwendungen, Konfgurationen und Daten. Die Orchestrierung beginnt mit der Anforderung eines Services, einer Anwendung oder einer Funktion im Access & Delivery Layer und endet mit der Koordination verschiedener IT-Schichten und Komponenten, die direkt oder auch indirekt in die vom Endnutzer angeforderte Leistung involviert sind. Aus sicherheitstechnischer Perspektive ist die Orchestrierung ein prozessualer Verbund von Komponenten, die in einer sicheren und zuverlässigen Art und Weise zusammenarbeiten müssen. Zu den für die Orchestrierung zu beachtenden Sicherheitsaspekten gehören: sichere Serviceübergabeschnittstellen, sichere Ressourcenbereitstellung, ein zuverlässiges Sicherheitsmonitoring der eingebundenen Ressourcen zur Laufzeit, so dass ein verdächtiges oder auch auffälliges Verhalten nicht unentdeckt bleibt. Das Resource Control Layer koordiniert und verbindet je verschiedene Schichten von Anwendungen, Netzen, virtuellen Maschinen und Hypervisoren, Betriebssystemen und Speicherbereichen und ist deshalb aus sicherheitstechnischem Blickwinkel ein besonders kritischer Bereich. Bedrohung Elevation of Privilege Unzulässige Erweiterung von Rechten Elevation of Privilege im Resources Control Layer Aufgrund der Tatsache, dass das Resources Control Layer (ROCL) die Bindung und Koordination der (virtualisierten, gleichwohl aber physikalisch mehreren Mandanten gleichzeitig bereitgestellten) Ressourcen im Cloud Computing übernimmt, ist das Risikopotenzial maßgeblich von der Durchsetzung sicherer Authentisierungs- und Autorisierungskonzepte und -maßnahmen (nicht nur bzgl. des Zutritts und des Zugangs, sondern auf bzgl. des Zugriffs bspw. via Managementkonsolen), der strikten Trennung von Zuständigkeiten (Separation of Duties) bzgl. der Tätigkeiten der CSP- und Sub-Provider Administratoren bestimmt wird. Erfolgreiches Elevation of Privilege im RCOL ermöglicht oder erleichtert den unbefugten Zugriff auf Archivsysteme und -datenträger, als auch auf die Konfguration der RCOL-Komponenten (u.u. durch den direkten Zutritt zu diesen) und damit Tampering, Information Disclosure und Denial of Service. Für externe Angreifer ist Elevation of Privilege vornehmlich die Folge eines erfolgreichen Spoofngs. Für Innentäter kommen sowohl böswillige und mittels Spoofng verschleierte Angriffe ( Repudiation), aber auch fahrlässiges Verhalten in Betracht. Zu Letzterem 134

135 Steckbriefe Teil 5: gehört insbesondere die unzureichende Kontrolle der ggf. versehentlichen Zuweisung von (erweiterten) Berechtigungen für die CSP- und die Sub-Provider Administratoren. Nicht auszuschließen ist bspw. die nicht erfolgte Löschung oder Deaktivierung von Berechtigungen eines Administrators von nicht mehr beschäftigten Mitarbeitern/ Partnern oder die fahrlässige Preisgabe von Authentifkationsinformationen. Innentäter mit Administratorrechten sind natürlich in besonderer Weise für den fahrlässigen oder böswilligen Zugriff auf die Daten und Ressourcen des RCOL privilegiert. Vor dem Hintergrund, dass eine unzulässige oder auch nur unbemerkte Erweiterung von Berechtigungen bzgl. des Zutritts, Zugangs und Zugriffs auf die Komponenten des Archivsystems im RCOL, den auf diesen Systemen gespeicherten Daten (Archivdaten und Konfgurationsdaten) und den aus dem RCOL stammenden Archivdatenträgern (bspw. Sicherungsbänder oder Wechselfestplatten) gestattet, erleichtert oder ermöglicht erfolgreiches Elevation of Privilege die Vorbereitung und Ausführung weiterer Attacken, wie bspw. Tampering, Information Disclosure oder Denial of Service. Elevation of Privilege wird durch die Cloud Security Alliance mehrfach in The Notorious Nine Cloud Computing Top Threats 2013 als eine ernstzunehmende Bedrohung für CloudUmgebungen benannt. Besondere Elevation of Privilege-Gefährdungen bzgl. des RCOL für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Elevation of PrivilegeAkteure der Cloud Service Provider Administrator (CSA) und der Sub-Provider Administrator (SPA) in Betracht. Dabei lassen sich zusätzlich zu den für das ADL aufgezeigten Bedrohungen vor allem folgende Einzelbedrohungsszenarien für Elevation of Privilege in der Cloud Management Plane erkennen: 1. Fehlendes Sicherheitsbewusstsein Eine unzureichende Zutrittsregelung und -kontrolle (IAM und Access Control) ermöglicht Angreifern über ein erfolgreiches Elevation of Privilege den unzulässigen Zutritt und Zugang ( Tampering und/oder Denial of Service) auf die Systeme und Komponenten im RCOL. Eine unzureichende Trennung von Zuständigkeiten (Separation of Duties) ermöglicht Angreifen über ein erfolgreiches Elevation of Privilege den unzulässigen Zugriff ( Tampering und/oder Information Disclosure) auf Konfgurationsdaten des RCOL. 2. Missbrauch von Berechtigungen Ein unbemerkter Missbrauch von Berechtigungen kann den Zugriff auf Archiv- oder Konfgurationsdaten ( Information Disclosure) ermöglichen, sowie ein Tampering dieser Daten und in der Folge weitere unbemerkte, weil verschleierte ( Repudiation) Attacken erleichtern (bspw. Denial of Service). Der unbemerkte Missbrauch von Berechtigungen für die Manipulation von Archivdaten und/oder Konfgurationsdaten ( Tampering) sowie einen verschleierten ( Repudiation) Zugriff auf die Ressourcen im RCOL wird erleichtert durch die Möglichkeit der unbefugten und unbemerkten Kenntnisnahme von Authentifzierungsinformationen ( Spoofng). 135

136 Teil 5: Steckbriefe Eintrittswahrscheinlichkeit gem. ALARP GELEGENTLICH Schadenswirkung gem. ALARP SEHR HOCH Risikobewertung INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU-Prozesse, SAD-02 und SAD-03, CSP-01/1, CSP-01/2, CSP-03, CSP-04, CSP-05 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: CSP-01/1, CSP-01/2, CSP-03, CSP-04/1, CSP-04/2 und CSP-04/5 Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, AES-03, AES-04, AES-05, AES-06, AES-07, AES-08, AES-11, NCS-03, DSS-01, DSS-02, DSS-03, DSS-04, DSS-06, DSS-09, PKI-02, IDM-01, IDM-02, IDM-04, IDM-05, IDM-06, SIM-01, SIM-02, SIM-04, SIM-05, BCM-01, SCM-01, HRR-01, HRR-02 Restrisiken Fehlende bzw. ungenügende Prozesse zur Erteilung, Genehmigung und Kontrolle von Nutzerkonten und Autorisierungen beim CSP und bzgl. der für den CSP tätigen Sub-Provider. Unzureichende Trennung und Kontrolle von Zuständigkeiten für das RCOL ( Separation of Duties). Unzureichende Authentifzierung und Autorisierung der CSP- und Sub-Provider Administratoren bzgl. des Zugriffs auf die Komponenten des RCOL. Ungenügende Sicherung der RCOL-Architektur/ -Infrastruktur und -Kommunikation durch den CSP. Fahrlässiges Fehlverhalten der CSP- und der Sub-Provider Administratoren. Konfgurationsfehler der CSP- und der Sub-Provider Administratoren. Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der einzelnen Akteure, sowie deren Umsetzung und Kontrolle, sollten die nachfolgend aufgeführten Themenfelder weiter untersucht werden: 136 Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: das Cloud Architekturkonzept des CSP, insbesondere bzgl. der Infrastruktur und des Betriebs der Speichersysteme und Speichernetze, die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich der Berechtigungs- und Rollenkonzepte sowie

137 Steckbriefe Teil 5: erforderlicher und etablierter Prozesse zur Zuweisung von Zugriffsrechten, als auch das Authentifzierungs- und Autorisierungskonzept für beauftragte Sub-Provider, die Disaster Recovery- / Notfallkonzepte und das Storage Security Konzepts des CSP, die Vertrags- und SLA-Gestaltung zwischen CSP und Subscriber. Überprüfung der Logging- und der Protokollierungs-Konzepte bzgl. aller relevanten Verbindungs- und Anmeldeereignisse, einschließlich der Konzepte und Prozesse bzgl. des Monitorings der Log-Daten und Protokolle, sowie bzgl. der bei Feststellung defnierter Ereignisse erforderlichen Maßnahmen. Überprüfung der Umsetzung und der Funktion des Loggings und der Protokollierung (Monitoring) bzgl. der Komponenten und derer Dienste im RCOL. 137

138 Teil 5: Steckbriefe 5.11 Tampering in der Cloud Management Plan Komponente Cloud Management Plane (CMP) Die Cloud Management Plane (CMP) ermöglicht gem. dem IETF Cloud Stack die Überwachung (Monitoring) und Administration der kompletten Cloud- Infrastruktur, um den ordnungsgemäßen Betrieb der Dienste, Anwendungen und Komponenten der Cloud gewährleisten zu können. Dazu weist die CMP generell folgende Funktionalitäten auf: Confguration Management und Services Lifecycle Management Services Registry und Service Discovery Monitoring, Logging, Accounting und Auditing Service Level Agreement (SLA) Management (SLAM) Security Services / Infrastructure Management. Zum Kern der in der CMP vorhandenen Querschnittsfunktionen gehören vor allem: Bedrohung die automatische Einbindung (der Einsatz) verschiedener Cloud Komponenten auf der Grundlage von Konfgurationsdaten und Einsatzrichtlinien, die Registrierung und Verwaltung von Services, Überwachungs- und Alarmfunktionen hinsichtlich des operativen Zustands der Cloud Umgebung, d. h. der Nutzung des Cloud Service, der Einhaltung der vereinbarten Leistungsparameter sowie des Zugriffs und des Auftretens sicherheitsrelevanter Ereignisse. Tampering Fälschung, Manipulation von Daten Tampering in der Cloud Management Plane Tampering stellt für die Cloud Management Plane eine äußerst kritische Bedrohungsfläche dar, denn über die in der CMP vorhandenen Funktionalitäten ist die Konfguration und Kontrolle aller relevanten Cloud- Dienste, einschließlich der Sicherheitsdienste möglich. Tampering in der CMP ist vor allem als Folge erfolgreicher Spoofng-Attacken möglich. Externe wie interne Angreifer erhalten dabei unter Nutzung gefälschter Identitäten und Ausnutzung unzureichender oder unsicherer Authentifzierungsmaßnahmen sowie ungenügender Überwachung von Zugriffen und Schnittstellen der CMP Zugriff auf kritische Querschnittsfunktionen der Cloud. Das verschafft ihnen die Möglichkeit, selbst sicherheitskritische Funktionen, wie bspw. das Monitoring von Cloud Komponenten und Services oder die Konfguration von Sicherheitsdiensten, zu kompromittieren. Damit wird es ihnen zweifellos erleichtert, nicht nur weitere und ggf. umfangreichere Attacken vorzubereiten, sondern ebenso unbemerkt auf die Kundendaten oder andere Cloud -Systeme bzw. InterCloud Funktionen zugreifen zu können Information Disclosure. 138

139 Steckbriefe Teil 5: Innentäter mit Administratorrechten sind dabei natürlich in besonderer Weise für den Zugriff auf die Funktionalitäten der Cloud Management Plane privilegiert. Tampering wird durch die Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 als eine der großen Bedrohungen benannt. Besondere Tampering-Attacken bzgl. der CMP für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Tampering-Akteure der Subscriber Administrator (SAD), der Cloud Service Provider Administrator (CSA) und die Administratoren des Cloud Sub-Providers in Betracht. Dabei lassen sich zusätzlich zu den für das ADL aufgezeigten Bedrohungen vor allem folgende Einzelbedrohungsszenarien für Tampering in der Cloud Management Plane erkennen: 1. Datenmanipulation auf Grund einer ungenügenden Trennung des Zugrifs auf die Funktionalitäten in der CMP Eine unzureichende Trennung der Systeme, Schnittstellen und Kommunikationsverbindungen der CMP sowie ein ungenügender Authentifzierungszwang (eine unsichere Managementkonsole mit unzureichender Mehr-Faktoren-Authentifzierung und ungenügende Trennung separater Benutzerkonten), ermöglichen einem Angreifer nach einer erfolgreichen Spoofng-Attacke den Zugriff auf die Funktionalitäten der CMP. In der Folge ist dieser in der Lage, mit einer Veränderung (Manipulation) Tampering von Konfgurationsdaten oder Einstellungen der Cloud-(Sicherheits-) Dienste nachfolgendes Spoofng zu erleichtern, und damit auch ein erneutes, ggf. auch wirkungsvolleres Tampering gestützt auf Elevation of Privilege mit ggf. nachfolgendem Information Disclosure durchzuführen, aber auch die korrekte Ausführung bzw. die Verfügbarkeit von Cloud-Service insgesamt zu beeinträchtigen ( Denial of Service). Hierunter ist ebenfalls die unzureichende oder gar fehlende Trennung von Zuständigkeiten in Bezug auf die Tätigkeiten der CSP- Administratoren zu verstehen. Denn die unzureichende oder gar fehlende Umsetzung eines Mandanten-orientierten Administrationskonzeptes seitens des CSP kann zur Folge haben, dass die CSP- Administratoren nicht getrennt nach Mandanten, sondern mandantenübergreifend Zugriff auf die Komponenten des SaaS Archivsystems haben. Auf Grund der im Allgemeinen sehr weitreichenden Berechtigungen dieser CSP- Administratoren, stellt dieses eine enorme Bedrohung für alle Sicherheitsziele dar und kann bei fahrlässigem Fehlverhalten seitens der Administratoren des CSP bzw. böswilligen Innentätern (des Subscribers wie des CSP) zu schwerwiegenden Schäden, wie bspw. Tampering, führen. 2. Datenmanipulation durch Hacking der CSP Architektur Ein Angreifer gelangt entweder nach erfolgreichem Spoofng oder über eine unzureichend gesicherte Architektur/Infrastruktur des CSP direkt an die CMP bzw. das Managment-Netzwerk des CSP (Hacking einer ungenügend gesicherten und ohne ausreichende Identitätsprüfung versehenden sowie von Außen erreichbaren Administrationsschicht). Dadurch ist einem Angreifer die Veränderung (Manipulation) Tampering von Konfgurationsdaten oder Einstellungen der Cloud-(Sicherheits-) Dienste möglich, um nachfolgendes Spoofng zu erleichtern und damit auch ein erneutes, ggf. auch wirkungsvolleres Tampering (gestützt auf Elevation of Privilege mit ggf. nach- 139

140 Teil 5: Steckbriefe folgendem Information Disclosure) zu ermöglichen, aber auch die korrekte Ausführung bzw. die Verfügbarkeit von Cloud-Service insgesamt zu beeinträchtigen ( Denial of Service). Eintrittswahrscheinlichkeit gem. ALARP VORSTELLBAR Schadenswirkung gem. ALARP SEHR HOCH Risikobewertung INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU-Prozesse, SAD-01, SAD-02/2, SAD-02/3 und SAD-03, CSP-01/2 und CSP-04 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: SEU-01, SAD-02/2, SAD-02/3, SAD-03/2 und SAD-03/3, Konfgurationstätigkeiten der CSP-Administratoren Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, IFS-02, AES-01, AES-02, AES-04, AES-05, AES-06, AES-07, AES-09, AES-13, NCS-01, NCS-02, NCS-03, DSS-01, DSS-02, DSS-03, DSS-04, DSS-05, DSS-08, PKI-01, PKI-02, PKI-03, PKI-04, IDM-01, IDM-04, IDM-06, SIM-04, BCM-01, SCM-01, HRR-01, HRR-02 Restrisiken Unzureichende Authentifzierung und Autorisierung der SAD bzgl. des Zugriffs auf die Elemente der CMP (unsichere Managementkonsolen). Ungenügende Sicherung der CMP Architektur und Kommunikation durch den CSP. Unsicherer Umgang mit Benutzerkennungen auf der Seite des Subscribers und des Sub-Providers. Fahrlässiges Fehlverhalten Administratoren. Konfgurationsfehler der CSP- Administratoren. der Mitarbeiter des Subscribers und der CSP- Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der einzelnen Akteure, sowie deren Umsetzung und Kontrolle, sollten die nachfolgend benannten Themenfelder Gegenstand weitergehender Untersuchungen sein: Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: 140 das Cloud Architekturkonzept des CSP, insbesondere bzgl. der Trennung / Alleinstellung der CMP,

141 Steckbriefe Teil 5: die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich der Gestaltung und Durchsetzung von zuverlässigen Berechtigungs- und Rollenkonzepten, Authentifzierungs- und Autorisierungskonzepte (hier insbesondere von Managementkonsolen in der CMP), die Vertrags- und SLA-Gestaltung zwischen CSP und Subscriber administrativer Kompetenzen, Monitoring, Logging und Audits. Monitoring von Logging und Log-Daten, sicherheitsrelevanter Informationen des CSP. Aggregation und bzgl. Monitoring 141

142 Teil 5: Steckbriefe 5.12 Denial of Service in der Cloud Management Plane Komponente Cloud Management Plane (CMP) Die Cloud Management Plane (CMP) ermöglicht gem. dem IETF Cloud Stack die Überwachung (Monitoring) und Administration der kompletten Cloud-Infrastruktur, um den ordnungsgemäßen Betrieb der Dienste, Anwendungen und Komponenten der Cloud gewährleisten zu können. Dazu weist die CMP generell folgende Funktionalitäten auf: Confguration Management und Services Lifecycle Management Services Registry und Service Discovery Monitoring, Logging, Accounting und Auditing Service Level Agreement (SLA) Management (SLAM) Security Services / Infrastructure Management. Zum Kern der in der CMP vorhandenen Querschnittsfunktionen gehören vor allem: Bedrohung die automatische Einbindung (der Einsatz) verschiedener Cloud Komponenten auf der Grundlage von Konfgurationsdaten und Einsatzrichtlinien, die Registrierung und Verwaltung von Services, Überwachungs- und Alarmfunktionen hinsichtlich des operativen Zustands der Cloud Umgebung, d. h. der Nutzung des Cloud Service, der Einhaltung der vereinbarten Leistungsparameter sowie des Zugriffs und des Auftretens sicherheitsrelevanter Ereignisse. Denial of Service Dienstverhinderung Denial of Service in der Cloud Management Plane Denial of Service stellt für die Cloud Management Plane eine außerordentlich schwerwiegende Bedrohungsfläche dar, denn damit ständen die in der CMP vorhandenen Funktionalitäten zur Konfguration und vor allem zur Kontrolle aller relevanten Cloud- Dienste, einschließlich der Sicherheitsdienste, nicht mehr zur Verfügung. Je nach gegebener Architektur hat dies den nicht mehr steuer- und kontrollierbaren, ordnungsgemäßen Betrieb der Dienste, Anwendungen und Komponenten der betroffenen Cloud-Umgebung zur Folge. Denial of Service aufgrund von Fehlkonfguration bzw. Fehlverhalten durch Innentäter (bspw. durch ein erfolgreiches Tampering bzgl. der Konfgurationsdaten von Komponenten des CMP-Monitoring bzw. des CMP-Accounting als Folge eines erfolgreichen Elevation of Privilege oder logischer Attacken durch externe Angreifer (entweder als reine DoSAttacken oder in der Folge eines erfolgreichen Spoofngs) ist längst nicht mehr nur vorstellbar. Denial of Service ist aber auch möglich als Folge fahrlässiger physischer Zugriffe auf eingesetzte Managementkomponenten. Innentäter mit Administratorrechten sind dabei natürlich in besonderer Weise für den Zugriff auf die Funktionalitäten der Cloud Mana- 142

143 Steckbriefe Teil 5: gement Plane privilegiert. Die Dienstverhinderung und der Datenverlust aufgrund von Denial of Service-Bedrohungen sind durch die Cloud Security Alliance in The Notorious Nine Cloud Computing Top Threats 2013 als zunehmende und häufg auftretende Bedrohungen benannt. Besondere Denial of Service-Gefährdungen bzgl. der CMP für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Denial of Service-Akteure der Subscriber Administrator (SAD), der Cloud Service Provider Administrator (CSA) und der Sub-Provider Administrator (SPA) in Betracht. Dabei lassen sich zusätzlich zu den für das ADL aufgezeigten Bedrohungen vor allem folgende Einzelbedrohungsszenarien für Elevation of Privilege in der Cloud Management Plane erkennen: 1. Ausfall von Komponenten in der CMP Störungen oder der Ausfall von Diensten, Anwendungen und Komponenten der CMP durch Konfgurationsfehler, Wartungsarbeiten, Programmfehler oder auch erfolgreich ausgeführte Attacken haben für den Subscriber ggf. nicht nur eine unerwartete Nichterreichbarkeit der SaaS Archivsystemdienste zur Folge. Insbesondere der Ausfall von Sicherheitskomponenten ermöglicht oder erleichtert externe wie interne Angriffe. 2. Fehlende Mandanten-Trennung/ Trennung von Zuständigkeiten (Separation of Duties) Die unzureichende oder gar fehlende Umsetzung eines Mandanten-orientiertes Administrationskonzeptes seitens des CSP kann zur Folge haben, dass die CSP- Administratoren nicht getrennt nach Mandanten, sondern mandantenübergreifend Zugriff auf die Konfguration und Überwachung der Komponenten des SaaS Archivsystems haben. Auf Grund der im Allgemeinen sehr weitreichenden Berechtigungen dieser CSP- Administratoren, stellt dieses eine enorme Bedrohung für alle Sicherheitsziele dar und kann bzgl. der Fällen von fahrlässigem Fehlverhalten seitens der Administratoren des CSP bzw. bei böswilligen Innentätern (des Subscribers wie des CSP) zu schwerwiegenden Schäden, wie bspw. Denial of Service, führen. 3. Unsichere, nicht redundant gestaltete Architektur Eine unsichere (nicht ausreichend vor DoS-Attacken etc. geschützte) sowie unzureichend redundant gestaltete Architektur/Infrastruktur auf der Seite des CSP führen bereits bei einem einfachen technischen Ausfall zu einer zumindest partiellen Nichterreichbarkeit des SaaS Archivsystem Service oder ungenügendem Monitoring des Betriebes. 4. Dienstverweigerung durch Sperrung von Benutzerkonten Fahrlässiges Fehlverhalten durch Administratoren des Subscribers oder CSP, bspw. bei einer Änderung vom Konfgurationsdaten, kann zu einer Sperrung von Benutzerkonten führen. Ebenso können böswillige Innentäter (des Subscribers wie des CSP), auf der Basis eines erfolgreichen Spoofngs und in der Folge eines Elevation of Privilege eine Sperrung von Benutzerkonten und damit eine Nichtverfügbarkeit des Service her- 143

144 Teil 5: Steckbriefe beiführen. 5. Ausfall durch nicht kommunizierte, nicht abgestimmte Prozesse Die Durchführung von unzureichend mit dem Subscriber abgestimmten und vereinbarten Wartungsarbeiten durch den CSP, können die Nichtverfügbarkeit von Komponenten und Funktionen sowie ggf. der kompletten SaaS Archivsystemanwendung für den SEU zur Folge haben. Eintrittswahrscheinlichkeit gem. ALARP GELEGENTLICH Schadenswirkung gem. ALARP HOCH Risikobewertung INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU- Prozesse, alle SAD- Prozesse, CSP-01/2, CSP-04 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: SEU-01, SAD-02/3, SAD-03/2 und SAD-03/3, Pflege- und Wartungsarbeiten der CSP-Administratoren, einschließlich Konfgurationstätigkeiten bzgl. Neuanlage, Löschung, Änderung von Benutzern oder Parametern etc. Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, IFS-02, AES-04, AES-07, AES-08, AES-11, AES-12, NCS-01, NCS-02, NCS-03, NCS-04, NCS-05, DSS-03, DSS-04, DSS-07, IDM-01, UIC-01, SIM-01, SIM-04, BCM-01, BCM-02, BCM-03, BCM-04, HRR-02 Restrisiken 144 Unzureichende Schulung von Mitarbeitern beim CSP und Subscriber. Unsichere oder fehlerhafte Konfguration von Sicherheitskomponenten. Unzureichende Aggregation und Bewertung sicherheitsrelevanter Ereignisse beim CSP. Unzureichende oder fehlende Maßnahmen bzgl. Szenarien Höherer Gewalt. Unzureichende Kommunikation zwischen CSP und Subscriber Wartungsmaßnahmen oder Änderung von Zugangsmechanismen. Unzureichende Authentifzierung und Autorisierung der SAD bzgl. des Zugriffs auf Komponenten oder Anwendungen der CMP (unsichere Managementkonsolen). Unzureichende Trennung und Kontrolle von Zuständigkeiten beim CSP ( Separation of Duties). Ungenügende Sicherung der CMP-Architektur und -Kommunikation durch den CSP. Fahrlässiges Fehlverhalten der Mitarbeiter des Subscribers und bezüglich der CSP-

145 Steckbriefe Teil 5: Administratoren. Konfgurationsfehler der CSP- Administratoren. Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der Vertragsparteien, sowie deren Umsetzung und Kontrolle, sollten die im Folgenden benannten Themen Gegenstand weiterer Betrachtungen sein: Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: das Cloud Architekturkonzept Mandanten-bezogenen Trennung Komponenten der CMP, die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich der Berechtigungs- und Rollenkonzepte, sowie erforderlicher und etablierter Prozesse zur Zuweisung von Zugriffsrechten, als auch das Authentifzierungs- und Autorisierungskonzept des Subscribers und des CSP insbesondere beim Zugriff auf die CMP, die Vertrags- und SLA-Gestaltung zwischen CSP und Subscriber bzgl. administrativer Kompetenzen, Monitoring, Logging und Audits. des von CSP, insbesondere bzgl. der Zuständigkeiten und logischer Prozesse bzgl. der Verwaltung von Subscriber- Mandanten, insbesondere bzgl. der Änderung, Anpassung und Kontrolle von Nutzerautorisierungen. Konzepte und Maßnahmen des CSP hinsichtlich des Monitorings und der Reaktion auf sicherheitsrelevante Ereignisse. Überprüfung der Logging- und der Protokollierungs- Konzepte bzgl. aller relevanten Verbindungs-, System- und Nutzerereignisse, einschließlich der Konzepte und Prozesse bzgl. des Monitorings der Log-Daten und Protokolle, sowie bzgl. der bei Feststellung defnierter Ereignisse erforderlichen Maßnahmen. Überprüfung der Umsetzung und der Funktion des Loggings und der Protokollierung (Monitoring) bzgl. der Dienste und Querschnittsfunktionen der Cloud Management Plane. 145

146 Teil 5: Steckbriefe 5.13 Elevation of Privilege in der Cloud Management Plane Komponente Cloud Management Plane (CMP) Die Cloud Management Plane (CMP) ermöglicht gem. dem IETF Cloud Stack die Überwachung (Monitoring) und Administration der kompletten Cloud-Infrastruktur, um den ordnungsgemäßen Betrieb der Dienste, Anwendungen und Komponenten der Cloud gewährleisten zu können. Dazu weist die CMP generell folgende Funktionalitäten auf: Confguration Management und Services Lifecycle Management Services Registry und Service Discovery Monitoring, Logging, Accounting und Auditing Service Level Agreement (SLA) Management (SLAM) Security Services / Infrastructure Management. Zum Kern der in der CMP vorhandenen Querschnittsfunktionen gehören vor allem: Bedrohung die automatische Einbindung (der Einsatz) verschiedener Cloud Komponenten auf der Grundlage von Konfgurationsdaten und Einsatzrichtlinien, die Registrierung und Verwaltung von Services, Überwachungs- und Alarmfunktionen hinsichtlich des operativen Zustands der Cloud Umgebung, d. h. der Nutzung des Cloud Service, der Einhaltung der vereinbarten Leistungsparameter sowie des Zugriffs und des Auftretens sicherheitsrelevanter Ereignisse. Elevation of Privilege Unzulässige Erweiterung von Rechten Elevation of Privilege in der Cloud Management Plane Elevation of Privilege ist eine Bedrohungsfläche für die CMP deren Risikopotenzial maßgeblich von der Durchsetzung sicherer Authentisierungs- und Autorisierungskonzepte und -maßnahmen (bspw. in Managementkonsolen), der strikte Trennung von Zuständigkeiten (Separation of Duties) innerhalb der CMP sowie der strikten Trennung der CMP von anderen Cloud- Schichten und externen Kommunikationsverbindungen bestimmt wird. Erfolgreiches Elevation of Privilege in der CMP ermöglicht oder erleichtert den unbefugten Zugriff auf kritische Querschnittsfunktionen, bspw. auf die Sicherheitsdienste der Cloud oder auch bzgl. der Konfgurationsdaten von Komponenten des CMP-Monitoring bzw. des CMP-Accounting und damit Tampering, Information Disclosure oder Denial of Service. Für externe Angreifer ist Elevation of Privilege vornehmlich die Folge eines erfolgreichen Spoofngs. Für Innentäter kommen sowohl böswillige und mittels Spoofng verschleierte Angriffe ( Repudiation), aber auch fahrlässiges Verhalten in Betracht. Zu Letzterem 146

147 Steckbriefe Teil 5: gehört insbesondere die unzureichende Kontrolle der ggf. versehentlichen Zuweisung von (erweiterten) Administratorberechtigungen. Nicht auszuschließen ist bspw. die nicht erfolgte Löschung oder Deaktivierung eines Administratorenkontos von nicht mehr beschäftigten Mitarbeitern/Partnern oder die fahrlässige Preisgabe von Authentifkationsinformationen. Vor dem Hintergrund, dass eine unzulässige oder auch nur unbemerkte Erweiterung von Berechtigungen ggf. den Zugriff auf die Cloud -Sicherheitsdienste in der CMP gestattet, erleichtert oder ermöglicht erfolgreiches Elevation of Privilege die Vorbereitung und Ausführung weiterer Attacken, wie bspw. Tampering, Information Disclosure oder Denial of Service. Elevation of Privilege wird durch die Cloud Security Alliance mehrfach in The Notorious Nine Cloud Computing Top Threats 2013 als eine ernstzunehmende Bedrohung für CloudUmgebungen benannt. Besondere Elevation of Privilege-Gefährdungen bzgl. der CMP für SaaS Archiving Für das Szenario SaaS Archivsystem kommen als privilegierte Elevation of PrivilegeAkteure der Subscriber Administrator (SAD), der Cloud Service Provider Administrator (CSA) und der Sub-Provider Administrator (SPA) in Betracht. Dabei lassen sich zusätzlich zu den für das ADL aufgezeigten Bedrohungen vor allem folgende Einzelbedrohungsszenarien für Elevation of Privilege in der Cloud Management Plane erkennen: 1. Missbrauch von Berechtigungen Ein unbemerkter Missbrauch von Berechtigungen kann den Zugriff auf Authentifkations- oder Konfgurationsdaten ( Information Disclosure) ermöglichen, sowie ein Tampering dieser Daten und in der Folge weitere unbemerkte, weil verschleierte ( Repudiation) Attacken erleichtern (bspw. Denial of Service). Der unbemerkte Missbrauch von Berechtigungen für die Manipulation von Benutzerkonten und/oder Konfgurationsdaten ( Tampering) sowie einen verschleierten ( Repudiation) Zugriff auf Funktionen der Cloud Management Plane wird erleichtert durch die Möglichkeit der unbefugten und unbemerkten Kenntnisnahme von Authentifzierungsinformationen ( Spoofng). Durch den unbemerkten oder auch verschleierten Zugriff auf die Cloud-Dienste in der CMP ist ein Angreifer in der Lage, die Einstellungen der Überwachungs- und Sicherheitsdienste der relevanten Cloud- Umgebung zu verändern ( Tampering), um so dann mittels weiterer Zugriffe oder Attacken (unerkannt) unter Umständen auf alle SaaS Archiv-Daten zuzugreifen und diese zu verändern ( Tampering), zu veröffentlichen ( Information Disclosure) oder zu löschen ( Denial of Service). 2. Fehlende Mandanten-Trennung/ Trennung von Zuständigkeiten (Separation of Duties) Die unzureichende oder gar fehlende Umsetzung eines Mandanten-orientiertes Administrationskonzeptes und die ungenügende oder gar fehlende Trennung von Zuständigkeiten seitens des CSP kann zur Folge haben, dass die CSP- Administratoren nicht getrennt nach Mandanten, sondern mandantenübergreifend Zugriff auf die Komponenten des SaaS Archivsystems haben. Auf Grund der im Allgemeinen sehr weitreichenden Berechtigungen dieser CSP- Administratoren, stellt dieses eine enorme Bedrohung für alle Sicherheitsziele dar und kann bzgl. der Fällen von fahr- 147

148 Teil 5: Steckbriefe lässigem Fehlverhalten seitens der Administratoren des CSP bzw. bei böswilligen Innentätern (des Subscribers wie des CSP) zu schwerwiegenden Schäden, wie bspw. ein unbemerktes Elevation of Pirvilege, führen. Eintrittswahrscheinlichkeit gem. ALARP VORSTELLBAR Schadenswirkung gem. ALARP HOCH Risikobewertung INAKZEPTABEL Prozesse, die von dieser Bedrohung direkt betrofen sind: alle SEU- Prozesse, SAD-01, SAD-02/2 und SAD-03, CSP-01/2 und CSP-04 Prozesse, bei welchen diese Bedrohung am ehesten zu erwarten ist: SAD-02/2, SAD-02/3, CSP-Administratoren SAD-03/2 und SAD-03/3, Konfgurationstätigkeiten der Sicherheitsanforderungen gemäß Teil I des Sicherheitsprofls: ISM-01, ISM-02, ISM-03, ISM-04, IFS-01, AES-03, AES-04, AES-05, AES-06, AES-07, AES-08, AES-11, NCS-03, DSS-01, DSS-02, DSS-03, DSS-04, DSS-06, DSS-09, PKI-02, IDM-01, IDM-02, IDM-04, IDM-05, IDM-06, SIM-01, SIM-02, SIM-04, SIM-05, BCM-01, SCM-01, HRR-01, HRR-02 Restrisiken Fehlende bzw. ungenügende Prozesse zur Erteilung, Genehmigung und Kontrolle von Nutzerkonten und Autorisierungen beim Subscriber und beim CSP. Unzureichende Authentifzierung und Autorisierung der SAD Administratoren des CSP bzgl. des Zugriffs auf die Funktionen der CMP. Ungenügende Sicherung der CMP-Architektur und -Kommunikation durch den CSP. Fahrlässiges Fehlverhalten Administratoren. Konfgurationsfehler der CSP- Administratoren. der Mitarbeiter des Subscribers und und der der CSP- Noch näher zu betrachtende Bereiche In Abhängigkeit von den Architekturkonzepten, Sicherheitskonzepten und -richtlinien der Vertragsparteien, sowie deren Umsetzung und Kontrolle, sollten die nachfolgend benannten Themenfelder Gegenstand weitergehender Untersuchungen sein: Überprüfung und ggf. Anpassung der Sicherheitskonzepte und -richtlinien auf der Grundlage einer validen Schutzbedarfsfeststellung, in Bezug auf die aktuell gegebene Risiko- und Bedrohungslage, d. h.: 148 das Cloud Architekturkonzept des CSP, insbesondere bzgl. der

149 Steckbriefe Teil 5: Trennung/Alleinstellung der CMP, die Sicherheitskonzepte und IT-Sicherheitsrichtlinien des CSP, des Subscribers und Sub-Providers, einschließlich der Berechtigungs- und Rollenkonzepte, sowie erforderlicher und etablierter Prozesse zur Zuweisung von Zugriffsrechten, als auch das Authentifzierungs- und Autorisierungskonzept des Subscribers und des CSP insbesondere beim Zugriff auf die CMP, die Vertrags- und SLA-Gestaltung zwischen CSP und Subscriber administrativer Kompetenzen, Monitoring, Logging und Audits. bzgl. Prozesse bzgl. der Verwaltung von Subscriber- Mandanten, insbesondere bzgl. der Änderung, Anpassung und Kontrolle von Nutzerautorisierungen. Überprüfung der Logging- und der Protokollierungs- Konzepte bzgl. aller relevanten Verbindungs-, System- und Nutzerereignisse, einschließlich der Konzepte und Prozesse bzgl. des Monitorings der Log-Daten und Protokolle, sowie bzgl. der bei Feststellung defnierter Ereignisse erforderlichen Maßnahmen. Überprüfung der Umsetzung und der Funktion des Loggings und der Protokollierung (Monitoring) bzgl. der Dienste und Querschnittsfunktionen der Cloud Management Plane. 149

150 Anhang IETF Cloud Stack Anhang IETF Cloud Stack 150