Protection Level Agreements Werkzeuge zur Vereinbarung von Sicherheitsanforderungen in Kunde-Dienstleister-Beziehungen

Bundesamt für Sicherheit in der Informationstechnik Postfach 20 03 63 53133 Bonn Tel.: +49 22899 9582-5599 E-Mail: [email protected] Internet: http://www.bsi.bund.de © Bundesamt für Sicherheit in der Informationstechnik 2010

Inhaltsverzeichnis

Inhaltsverzeichnis 1

Motivation und Gliederung.........................................................................................................7

2

Serice Level Management – Prozess zur Steuerung der Servicequalität....................................8

2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 2.2.9 2.2.10 2.3

3 3.1 3.2 3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 3.4.1 3.4.2

4 4.1 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.3.3 4.4 4.4.1 4.4.2 4.5 4.5.1

Ziele im Service Level Management.................................................................................................8 Service Level Management nach ITIL® V3......................................................................................9 Entwicklung von Vorlagen für Service Level Agreements und anderer Dokumente..................10 Ermittlung, Dokumentation und Vereinbarung von Anforderungen an neue IT-Services und die Erstellung von Service Level Requirements...............................................................................10 Überwachung der Serviceleistung unter Berücksichtigung der in SLAs vereinbarten Leistungen ...................................................................................................................................................10 Messung und Verbesserung der Kundenzufriedenheit................................................................11 Laufende Bewertung und Überarbeitung von unterstützenden Vereinbarungen und des ServiceUmfangs.....................................................................................................................................11 Erstellung von Service Reports..................................................................................................11 Durchführung von Service Reviews und die Initiierung eines Service-VerbesserungsProgramms (SIP)........................................................................................................................11 Laufende Bewertung und Überarbeitung von SLAs, des Service-Umfangs und unterstützender Vereinbarungen..........................................................................................................................12 Pflege von Kontakten und Beziehungen.....................................................................................12 Beschwerden und Lob................................................................................................................13 Rollen und Verantwortlichkeiten.....................................................................................................13

Service Level Agreements........................................................................................................15 Definition und Begriffsklärung........................................................................................................15 Ziele von Service Level Agreements...............................................................................................19 Herausforderungen und Voraussetzungen.......................................................................................21 Akzeptanz von Service Level Agreements.................................................................................21 Absicherung von Leistungszusagen............................................................................................22 Wahrnehmung der Kundenrolle.................................................................................................22 Besetzung des Service Level Managers......................................................................................23 Klare Verantwortlichkeiten........................................................................................................23 Gliederung und Inhalte von Service Level Agreements...................................................................23 Einleitung...................................................................................................................................23 Aufbau und Strukturierung - Gliederungsvorschlag...................................................................25

Grundlagen von Protection Level Agreements.........................................................................31 Ausgangslage..................................................................................................................................31 Qualitity of Protection und Protection Level Agreements...............................................................32 Quality of Protection..................................................................................................................33 Protection Level Agreement.......................................................................................................33 Ziele von Protection Level Agreements...........................................................................................34 Ziele im Interesse von Kunde und Dienstleister:........................................................................34 Ziele im Interesse des Dienstleisters:..........................................................................................35 Ziele im Interesse des Kunden:...................................................................................................35 Voraussetzungen und Erfolgsfaktoren.............................................................................................36 Voraussetzungen........................................................................................................................36 Erfolgsfaktoren...........................................................................................................................38 Inhalte von Protection Level Agreements........................................................................................40 Entkopplung von Sicherheitsanforderungen...............................................................................40

Bundesamt für Sicherheit in der Informationstechnik

3

Inhaltsverzeichnis

4.5.2 4.5.3 4.5.4

5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.8.1 5.8.2 5.8.3 5.9 5.10 5.11 5.12

6 6.1 6.2 6.3 6.4 6.5 6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 6.6

7 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.2.7 7.3 7.3.1 7.3.2

Sicherheitsgarantien...................................................................................................................41 Prozesskenngrößen.....................................................................................................................42 Technische Parameter.................................................................................................................43

PLA-Template...........................................................................................................................44 Vorüberlegungen.............................................................................................................................44 Lösungsansatz.................................................................................................................................46 Szenarien.........................................................................................................................................47 Gliederung.......................................................................................................................................49 Abschnitt 1: Einleitung/Präambel....................................................................................................51 Abschnitt 2: Grundlagen der Vereinbarung.....................................................................................51 Abschnitt 3: Beschreibung des IT-Services.....................................................................................52 Abschnitt 4: Vereinbarung des Schutzniveaus.................................................................................53 Sicherheitsziele...........................................................................................................................54 Erweiterte Schutzziele................................................................................................................56 Sicherheitsgarantien...................................................................................................................57 Abschnitt 5: Audit-Berechtigungen.................................................................................................62 Abschnitt 6: Kommunikation und Berichtswesen............................................................................63 Abschnitt 7: Juristischer Gegenstand der Vereinbarung..................................................................64 Abschnitt 8: Unterschriften..............................................................................................................64

Protection Level Management – PLM......................................................................................65 Der PLM-Prozess – Einleitung........................................................................................................65 Vergleich SLM und PLM................................................................................................................66 Rollen im PLM................................................................................................................................68 Aufbau der Prozessbeschreibung.....................................................................................................69 Verfahren im PLM..........................................................................................................................70 Ermittlung von Schutzanforderungen.........................................................................................70 Vereinbarung von PLAs und Absicherung.................................................................................73 Überwachung von PLAs.............................................................................................................75 Aktualisierung/Überarbeitung von PLAs...................................................................................78 Kontaktpflege.............................................................................................................................82 Integration in die Aufbauorganisation.............................................................................................83

Automatisierte Verarbeitung von PLAs im SOA-Umfeld........................................................85 Serviceorientierte Architekturen (SOA)..........................................................................................85 Sicherheitsstandards für Web Services............................................................................................87 WS-Security...............................................................................................................................88 WS-SecureConversation.............................................................................................................88 WS-Trust....................................................................................................................................89 WS-Policy/WS-SecurityPolicy...................................................................................................90 WS-MetaDataExchange.............................................................................................................90 WS-Agreement...........................................................................................................................91 Bewertung..................................................................................................................................91 Lösungsmöglichkeiten.....................................................................................................................92 SOA Security Framework..........................................................................................................92 Vereinbarung von Sicherheit durch standardisierte Bausteine....................................................93

8

Resümee und Ausblick..............................................................................................................96

9

Anhang......................................................................................................................................98

4

Bundesamt für Sicherheit in der Informationstechnik

Inhaltsverzeichnis

9.1 9.2 9.3

Glossar.............................................................................................................................................98 Literaturverzeichnis.......................................................................................................................100 Stichwort- und Abkürzungsverzeichnis.........................................................................................101

Abbildungsverzeichnis Abbildung 1: SLA-Beziehungen........................................................................................................16 Abbildung 2: Strukturen von Service Level Agreements...................................................................18 Abbildung 3: Ziele des Einsatzes von SLAs [SLA-Dissertation]......................................................19 Abbildung 4: Messbarkeit und Vertrauen in Sicherheitsgarantien.....................................................37 Abbildung 5: Sicherheitsziele und Maßnahmen im PLA...................................................................46 Abbildung 6: Auftragsverhältnisse in serviceorientierten Architekturen...........................................47 Abbildung 7: Vergleich zum SLA: Gleich bleibende Punkte sind hervorgehoben (Fettdruck).........49 Abbildung 8: Kombinierter SLA/PLA...............................................................................................50 Abbildung 9: Verfahren im Protection Level Management...............................................................65 Abbildung 10: „Späte Bindung“ von Diensten in der SOA...............................................................86 Abbildung 11: Dynamische Kunde-Dienstleister-Beziehungen in einer SOA (Beispiel)..................87 Abbildung 12: Relevante WS-Standards und ihre Beziehungen untereinander.................................91 Abbildung 13: Protection Level Agreements auf der Basis standardisierter Maßnahmenbündel (Bausteine)..........................................................................................................................................95

Tabellenverzeichnis Tabelle 1: PLA-Unterabschnitte im Abschnitt 1................................................................................51 Tabelle 2: PLA-Unterabschnitte im Abschnitt 2................................................................................51 Tabelle 3: PLA-Unterabschnitte im Abschnitt 3................................................................................52 Tabelle 4: PLA-Unterabschnitte im Abschnitt 4................................................................................53 Tabelle 5: PLA-Unterabschnitte im Abschnitt 5................................................................................62 Tabelle 6: PLA-Unterabschnitte im Abschnitt 6................................................................................64 Tabelle 7: PLA-Unterabschnitte im Abschnitt 7................................................................................64 Tabelle 8: Vergleich SLM/PLM.........................................................................................................67 Tabelle 9: Rollen im Protection Level Management..........................................................................69 Tabelle 10: Verfahrensübersicht Ermittlung von Anforderungen an PLA.........................................70 Tabelle 11: Verfahrensbeschreibung Ermittlung von Anforderungen an PLA..................................72 Tabelle 12: Verfahrensübersicht Vereinbarung von PLAs und Absicherung....................................73

Bundesamt für Sicherheit in der Informationstechnik

5

Inhaltsverzeichnis

Tabelle 13: Verfahrensbeschreibung Vereinbarung von PLAs und Absicherung.............................75 Tabelle 14: Verfahrensübersicht Überwachung von PLA..................................................................75 Tabelle 15: Verfahrensbeschreibung Überwachung von PLA...........................................................78 Tabelle 16: Verfahrensübersicht Aktualisierung/Überarbeitung von PLAs.......................................78 Tabelle 17: Verfahrensbeschreibung Aktualisierung/Überarbeitung von PLAs................................81 Tabelle 18: Verfahrensübersicht Kontaktpflege.................................................................................82 Tabelle 19: Verfahrensbeschreibung Kontaktpflege..........................................................................83 Tabelle 20: Verfügbare Standards: WS-Security...............................................................................88 Tabelle 21: Verfügbare Standards: WS-SecureConversation............................................................89 Tabelle 22: Verfügbare Standards: WS-Trust....................................................................................89 Tabelle 23: Verfügbare Standards: WS-SecurityPolicy.....................................................................90 Tabelle 24: Verfügbare Standards: WS-MetaDataExchange.............................................................90 Tabelle 25: Verfügbare Standards: WS-Agreement...........................................................................91 Tabelle 26: Glossar.............................................................................................................................99

6

Bundesamt für Sicherheit in der Informationstechnik

Motivation und Gliederung 1

1

Motivation und Gliederung

Sicherheitsanforderungen an die IT rücken in den letzten Jahren zunehmend in das Sichtfeld des Managements. Es haben sich Standards etabliert, die den Aufbau eines Informationssicherheitsmanagementsystems (ISMS) unterstützen und vergleichbar machen. Der Fokus dieser Standards, auch des im öffentlichen Bereich vorherrschenden Standards ISO 27001 [ISO 27001] auf Basis von IT-Grundschutz, liegt auf einem geschlossenen Eigenbetrieb der IT oder einem ganzheitlichen Outsourcing. Die Auslagerung des Betriebs von Komponenten, einzelnen Anwendungen und RZ-Kapazitäten an verschiedene spezialisierte Dienstleister ist aber bereits Alltag. Diese Studie betrachtet Chancen und Möglichkeiten von Protection Level Agreements (PLAs) als Werkzeug zur Vereinbarung von Sicherheitsanforderungen und Sicherheitsgarantien in Auftraggeber-Dienstleister-Beziehungen. Der professionelle Umgang mit den funktionalen und qualitativen Anforderungen an solche Dienstleistungen hat in Form des Service-Level-Managements nicht nur Eingang in die Unternehmenskultur gefunden, sondern findet in Standards wie ITIL und ISO 20000 auch einen akzeptierten Rahmen. Die Kapitel 2 und 3 geben dazu einen Überblick. Im Bereich der ISMS haben sich ähnliche Managementinstrumente bisher nicht durchsetzen können. Theoretisch könnten Sicherheitsanforderungen Teil der funktionalen Spezifikation eines Service-Level-Agreements (SLA) sein, doch scheitert dies in der Praxis an grundlegenden Problemen, die in Kapitel 4 untersucht werden: 1. Was sind meine Sicherheitsanforderungen, und wie kommuniziere ich diese meinem Dienstleister? 2. Wie können die Sicherheitsanforderungen in einer immer tiefer werdenden Kette von Subauftragnehmern eingehalten werden? Eine Antwort auf diese Fragen soll Kapitel 5 liefern, in dem ein Ansatz und Inhalte für eine konkrete Vereinbarung – ein Protection-Level-Agreement (PLA) – zwischen zwei Parteien entworfen werden. Kapitel 6 zeigt, wie sich die aus dem Service-Level-Management bekannten Prozesse in ein Protection-Level-Management übersetzen lassen. Die Einführung von serviceorientierten Architekturen (SOA) verstärkt den oben geschilderten Trend zur Diversifizierung. SOA ermöglicht es, mehr und kleinteiligere Services auszulagern, so dass ein tiefes und dynamisches Geflecht von Dienstleistern und Subdienstleistern entsteht. Im Extremfall – der Orchestrierung von Diensten zur Laufzeit („late binding“), werden Vertragsverhältnisse automatisiert und dynamisch gebildet. Kapitel 7 untersucht dafür notwendige Ansätze für eine automatisierte Verhandlung von PLAs. Das Resümee und der Ausblick in Kapitel 8 zeigen auf, wie schon jetzt Sicherheitsanforderungen an Dienstleister kommuniziert werden können und welche Entwicklungen in der Zukunft zu erwarten sind.

Bundesamt für Sicherheit in der Informationstechnik

7

2 Serice Level Management – Prozess zur Steuerung der Servicequalität

2

Serice Level Management – Prozess zur Steuerung der Servicequalität

2.1

Ziele im Service Level Management

Die Bedeutung von Informationstechnik für die Erfüllung verschiedener Fachaufgaben in der Verwaltung ist im Laufe der letzten Jahre stetig gestiegen. Viele Verwaltungsaufgaben sind heute ohne die Nutzung von IT nicht mehr oder nur in deutlich geringerer Qualität und Quantität zu leisten. Durch IT ist es möglich geworden, Prozess- und Postlaufzeiten zu reduzieren (z. B. durch E-Mail oder Dokumentenmanagementsysteme) oder ganze Fachaufgaben weitflächig elektronisch zu unterstützten (z. B. Besoldung, Personalwesen oder Dienstreisen). Für viele Fachabteilungen hat die IT heute eine so hohe Bedeutung erreicht, dass diese förmlich von verfügbarer und sicherer IT abhängig sind. Die Qualität der IT-Services ist damit nicht nur entscheidend für die Wirtschaftlichkeit der Aufgabenerfüllung, sondern grundsätzlich für die Funktionsfähigkeit der modernen Verwaltung. Die IT hat sich damit von der reinen Unterstützungsfunktion mit einem technischen Betrieb zu einer Stelle gewandelt, die viele Aufgaben überhaupt erst ermöglicht. Sie agiert häufig als Motor von Modernisierung und Prozessveränderung in der Verwaltung. In dieser neuen Rolle werden an die IT-Organisationen hohe Anforderungen hinsichtlich der Qualität der angebotenen Leistungen gestellt. Ein weiterer Trend ist die zunehmende Zentralisierung der IT-Aufgaben. Dieser betrifft sowohl Unternehmen als auch Behörden. In IT-Organisationen der Bundesverwaltung bringt, z. B. Die Verlagerung von IT-Aufgaben in die Dienstleistungszentren IT mit sich: Hatten behördeninterne Dienstleister noch vor kurzer Zeit eine förmliche „Auftrags- und Bestandsgarantie“, ist heute ein aktiver Wettbewerb zwischen verschiedenen IT-Organisationen zu beobachten. Verbunden mit knapper werdenden Haushaltsmitteln und der höheren Transparenz des Mittelverbrauchs durch Verfahren wie die Kosten-Leistungs-Rechnung, die Budgetierung oder die Produkthaushalte, führt dies dazu, dass eine IT-Organisation zunehmend an ihrer Leistungsfähigkeit und ihren Leistungen aus Sicht der Nutzer gemessen wird. Schrittweise bildet sich zwischen der IT und den nutzenden Fachbereichen eine Kunde-Dienstleister-Beziehung aus, die eine andere Steuerung verlangt, als es bisher in der Verwaltungsorganisation üblich war. Um der gestiegenen Bedeutung der IT auf der einen und den ebenfalls gestiegenen Erwartungen von Nutzern auf der anderen Seite gerecht zu werden, wurden in vielen Behörden Projekte zur Reorganisation der IT ins Leben gerufen. Inhaltlich war es hierbei in der Regel Aufgabe, die eigene IT-Organisation an den Empfehlungen der ITIL® (IT Infrastructure Library) auszurichten. Hiermit einher geht eine Optimierung von Prozessen und Abläufen in der IT-Organisation sowie eine stärkere Fokussierung auf die Bedürfnisse von Kunden und Anwendern. Entsprechend wurde z. B. auch schon im Regierungsprogramm „Moderner Staat – Moderne Verwaltung“ eine stärkere Nutzerorientierung gefordert ([EGov2.0]: „Die Verwaltung orientiert sich an Wirtschaftlichkeit und den Bedürfnissen der Nutzerinnen und Nutzer“).

8

Bundesamt für Sicherheit in der Informationstechnik

Serice Level Management – Prozess zur Steuerung der Servicequalität 2

Gerade mit der Bildung der Dienstleistungszentren IT (DLZ-IT) in der Bundesverwaltung erlangt die Beziehung zwischen den verschiedenen Fachbereichen in den verschiedenen Behörden als Servicenehmer und den DLZ-IT als Servicegeber eine neue Qualität. War es bisher größtenteils noch möglich, die Leistungen der IT über interne Einflussmöglichkeiten als Teil der eigenen Organisation zu steuern, verlangen neue Organisationsformen auch neue Steuerungs- und Beeinflussungsmöglichkeiten. Kunden und Anwender erwarten von der IT-Organisation zwar nach wie vor, dass die IT in der Lage ist, technische Einzelkomponenten auf qualitativ angemessenem Niveau zu betreiben und bereitzustellen. Darüber hinaus wird aber verlangt, dass diese Einzelkomponenten in ihrem Zusammenwirken einen wirklichen Nutzen für die Verwaltung darstellen und zuverlässig nutzbar sind. In [ITIL 2007] wird für diese Ausrichtung der Begriff des IT-Service geprägt. Dabei sollte die Art und Weise der technischen Realisierung aus dem Blickwinkel der Kunden gesehen eher in den Hintergrund rücken. Vorrangig soll der IT-Service einen spür und möglichst auch messbaren Nutzen für die Aufgaben des Fachbereichs bringen. Die IT wandelt sich also immer mehr von der bloßen Bereitstellung technischer Komponenten hin zu einem starken Partner der Fachbereiche. Anwender müssen sich darauf verlassen können, dass IT-Services funktionieren, wie es erwartet – besser noch vereinbart – wurde. Stabilität, Sicherheit und Verlässlichkeit von IT-Services sind heute häufig wichtiger als technische Innovationen oder der Einsatz neuester Technologien. Die IT soll wissen, welche Leistungen in welcher Qualität konsistent erbracht werden können und dies auch verlässlich, transparent und überprüfbar zusichern. Ein Ansatz, der diese Zielsetzung umfassend verfolgt, lässt sich im „Service Level Management“ finden. So definiert [ITIL 2007] als Ziel des Service Level Management die Sicherstellung, „dass alle operativen IT-Services und ihre Leistung konsistent und professionell durch die ITOrganisation gemessen werden und dass Services und erstellte Reports den Bedarf von Business und Kunden treffen.“ Auch die [ISO 20000] sagt, „Ziel des Service Level Managements ist es, Service Levels zu definieren, zu vereinbaren, diese aufzuzeichnen und zu steuern.“ Damit ist der Prozess des Service Level Managements geeignet, die Erfüllung der beschriebenen Anforderungen an moderne IT-Organisationen der Verwaltung zu erfüllen. Neben den in Kapitel 3 ausführlich beschriebenen Service Level Agreements (SLAs) soll noch kurz auf den gesamten Prozess des Service Level Managements eingegangen werden. Dies erleichtert die spätere Einordnung von Service Level Agreements im Kontext der gesamten Prozesslandschaft und bewahrt vor dem ein oder anderen Fehler im Umgang mit SLAs.

2.2

Service Level Management nach ITIL® V3

Nach [ITIL 2007] besteht der Prozess Service Level Management aus zehn Komponenten bzw. Verfahren, die im Folgenden kurz vorgestellt werden. Hierbei wird bewusst der Fokus auf die Aktivitäten gelegt, die für die Formulierung und Vereinbarung von Service Level Agreements von Relevanz sind.

Bundesamt für Sicherheit in der Informationstechnik

9

2 Serice Level Management – Prozess zur Steuerung der Servicequalität

2.2.1 Entwicklung von Vorlagen für Service Level Agreements und anderer Dokumente Auf Basis des Servicekatalogs soll für die SLAs eine Struktur entwickelt werden, die sicherstellt, dass alle Services und alle Kunden optimal abgedeckt werden. Hierzu gibt es verschiedene Gestaltungsmöglichkeiten der Templates, die in Kapitel 3.4 näher erläutert werden. Die Struktur soll möglichst als Standardtemplate auch für Service Level Requirements (SLRs) und Operational Level Agreements (OLAs) Verwendung finden. SLAs sollten in klarer Sprache verfasst werden.

2.2.2 Ermittlung, Dokumentation und Vereinbarung von Anforderungen an neue IT-Services und die Erstellung von Service Level Requirements Die Ermittlung und Dokumentation von Service Level Requirements ist als Vorstufe und Basis zur späteren Formulierung und Aushandlung von Service Level Agreements zu sehen. In einem iterativen Prozess sollen aus dem Service Level Management heraus gemeinsam mit dem Kunden seine Erwartungen und Bedürfnisse hinsichtlich der Qualität des IT-Services ermittelt und aufgenommen werden. Diese Erwartungen sollen anschließend mit den tatsächlich leistbaren Servicekomponenten der ITOrganisation abgeglichen werden. Hierzu gehören z. B. die Fähigkeit, eine gewünschte Verfügbarkeit oder Kapazität bereitstellen zu können, aber auch, das notwendige Sicherheitsniveau und Anforderungen im Notfallmanagement bereitzustellen.

2.2.3 Überwachung der Serviceleistung unter Berücksichtigung der in SLAs vereinbarten Leistungen Bei der Formulierung von Service Level Agreements gilt die Regel, dass nur das vereinbart werden darf, was auch gemessen werden kann. Hierbei ist es wichtig, dass die Monitoring-Ergebnisse die Sicht des Kunden widerspiegeln und nicht auf eine technische IT-Sicht beschränkt bleiben. Darüber hinaus ist zu beachten, dass die Verfügbarkeit einzelner IT-Komponenten noch nicht bedeutet, dass der komplette IT-Service auch wie vom Kunden erwartet funktioniert. So kann z. B. ein NetzwerkHub aus technischer Sicht noch als verfügbar definiert werden, wenn der Anwender schon mehrere Minuten für einen einfachen Datenzugriff benötigt. In der Praxis lässt sich in diesem Zusammenhang häufig beobachten, dass in SLAs Vereinbarungen getroffen werden, die in der Praxis auf Seiten der IT-Organisation nicht umgesetzt werden. So werden häufig in SLAs Eskalationswege beschrieben, die für bestimmte Störungen in bestimmten Zeiten greifen sollen. Diese Eskalationswege werden aber dem Service Desk in der IT nicht bekannt gegeben, so dass diese in der Praxis nicht greifen.

10

Bundesamt für Sicherheit in der Informationstechnik

Serice Level Management – Prozess zur Steuerung der Servicequalität 2

2.2.4 Messung und Verbesserung der Kundenzufriedenheit Neben der technisch überprüfbaren Servicequalität sollten auch die sogenannten „weichen Faktoren“ mit in den Blickwinkel des Service Level Managements aufgenommen werden. Hier ist das Augenmerk in erster Linie auf die Überwachung der Kundenzufriedenheit zu legen. Der SLM-Prozess verlangt, dass die Kundenzufriedenheit regelmäßig gemessen wird. Dies kann z. B. über Fragebögen und Umfragen erfolgen, oder auch über die Analyse von Beschwerden und natürlich Lob gegenüber dem Service Desk. Wie auch im Monitoring von Technologiekomponenten praktiziert sollten im SLA entsprechende Zielwerte vereinbarten werden, über die regelmäßig berichtet wird (siehe auch Kapitel 3).

2.2.5 Laufende Bewertung und Überarbeitung von unterstützenden Vereinbarungen und des Service-Umfangs Ein immer wieder zu beobachtender Fehler im Service Level Management ist die Vereinbarung von Service-Leistungen in SLAs mit Kunden, ohne dass diese im Innenverhältnis abgesichert sind. Ein Beispiel wären die häufig in SLAs vereinbarten Wiederherstellungs- und Reaktionszeiten. Hier ist es wichtig, sowohl mit der internen IT-Abteilung also auch mit externen Lieferanten zu klären, ob die im SLA vereinbarten Qualitäten auch tatsächlich realisiert werden können. Idealerweise werden diese Zusagen in unterstützenden Vereinbarungen dokumentiert und analog der Steuerung im SLA mit einem regelmäßigen Monitoring und Berichten überprüft.

2.2.6 Erstellung von Service Reports Der Service-Level-Management-Prozess (SLM-Prozess) verlangt eine hohes Maß an Transparenz von IT-Dienstleistern gegenüber den Kunden. Diese Transparenz wird u. a. über regelmäßig erstellte Berichte erreicht. Ziel und Inhalt ist es, alle in den jeweiligen SLA vereinbarten Qualitätsparameter überprüfen zu können und den Kunden verständliche Berichte hierüber bereitzustellen. Dabei sollen die Berichtsinhalte, mechanismen, intervalle, formate und empfänger schon im Vorfeld mit den Kunden abgestimmt sein. Der Aufbau geeigneter Monitoringverfahren und Möglichkeiten der Berichtserstellung ist wesentlicher Bestandteil des SLM-Prozesses und ein häufig unterschätzter Aufwand.

2.2.7 Durchführung von Service Reviews und die Initiierung eines ServiceVerbesserungs-Programms Wesentlicher Inhalt im SLM-Prozess ist die laufende Pflege der Beziehungen zwischen dem Kunden und dem IT-Dienstleister. Ziel ist es hierbei, die Bedürfnisse des Kunden zu kennen und ihm einen möglichst optimalen IT-Service bereitzustellen. Bundesamt für Sicherheit in der Informationstechnik

11

2 Serice Level Management – Prozess zur Steuerung der Servicequalität

Ein Mittel, um dieses Ziel zu erreichen, sind sogenannte Service Review Meetings, d. h. regelmäßig stattfindende Treffen mit dem Kunden, in welchen über die wahrgenommene Servicequalität gesprochen wird. Je nach Erkenntnis aus den Service Reviews sollen weitere Aktivitäten angestoßen werden. Erhält der IT-Dienstleister z. B. die Rückmeldung, dass bestimmte, in SLAs vereinbarte Servicequalitäten nicht zur Zufriedenheit erbracht worden sind, sollen entsprechende Schritte zur Verbesserung eingeleitet werden. Diese Serviceverbesserung hat auch hier wieder Auswirkungen auf die SLAs sowie die unterstützenden Vereinbarungen.

2.2.8 Laufende Bewertung und Überarbeitung von SLAs, des Service-Umfangs und unterstützender Vereinbarungen Für das Verständnis der Aufgaben im Service Level Management ist es wichtig zu verinnerlichen, dass sämtliche Dokumente des Prozesses, vor allem aber die SLAs und unterstützenden Vereinbarungen keine statischen Dokumente sind, sondern einer stetigen Anpassung unterliegen. Anforderungen auf Seiten der Kunden ändern sich. Serviceziele, die vor zwei Jahren noch besonders wichtig und dringlich waren, könnten im Laufe der Zeit in der Bedeutung zurückgegangen sein, Nutzungsauswertungen ermöglichen eine differenziertere Betrachtung von Verfügbarkeitsanforderungen, oder technische Möglichkeiten machen vor einiger Zeit noch unerreichbare Ziele nun möglich usw. Damit sichergestellt werden kann, dass diese Anforderungen bedient und Chancen zur Verbesserung genutzt werden, sollten regelmäßige Reviews die SLAs und unterstützenden Vereinbarungen aktuell halten.

2.2.9 Pflege von Kontakten und Beziehungen Durch das Service Level Management soll insbesondere die Beziehung zwischen der IT und den eigentlichen Kernaufgaben der Kundenorganisation verbessert werden. Hierzu soll das SLM eine vertrauensvolle Zusammenarbeit mit den Fachbereichen anstreben. Kern dieser Zusammenarbeit ist es, genau zu verstehen, welche IT-Services in welchen Fachaufgaben unterstützen und welche Zusammenhänge zwischen IT-Komponenten und Aufgabenerfüllung der Fachbereiche bestehen. Der IT-Dienstleister soll weniger als einfacher ITLieferant, sondern vielmehr als Partner der Fachbereiche aufgestellt werden und agieren. Es wird verlangt, dass der IT-Dienstleister wichtige Personen in den Fachbereichen kennt, flexibel auf Anforderungen und neue Bedürfnisse reagieren kann und so ihr Serviceangebot proaktiv und im Sinne des Kundennutzen vermarkten kann.

12

Bundesamt für Sicherheit in der Informationstechnik

Serice Level Management – Prozess zur Steuerung der Servicequalität 2

2.2.10 Beschwerden und Lob Ein gesondertes Augenmerk im Service Level Management gilt der Behandlung von Beschwerden und Lob. Während aus positiven Rückmeldungen der Kunden Schlüsse für die Weiterentwicklung der eigene Stärken gezogen werden können und so auch die Kundenzufriedenheit belegt wird, ist die Behandlung von negativen Rückmeldungen häufig anspruchsvoll. Neben der Pflicht, alle Rückmeldungen zu dokumentieren, wird im SLM verlangt, allen Beschwerden nachzugehen – verbunden mit dem Ziel, die Zufriedenheit des Beschwerdeführers wieder herzustellen. Hierfür sollen auch schon im SLA Beschwerde- und Eskalationswege definiert und nach innen entsprechend abgesichert werden.

2.3

Rollen und Verantwortlichkeiten

Im IT-Servicemanagement werden zusammenhängende Aktivitäten eines Prozesses in Rollen zusammengefasst und in Form einer Rollenbeschreibung dargestellt. Neben den Aktivitäten enthalten Rollenbeschreibung auch immer Verantwortlichkeiten sowie Kompetenzen, d. h. Rechte und Pflichten des Rolleninhabers. Diese Rollenbeschreibungen werden bei Einführung eines Prozesses auf konkrete Personen bzw. Stellen übertragen, wobei es in der Praxis die Regel ist, dass eine Person mehrere Rollen wahrnimmt. Im Service Level Management sind nach [ITIL 2007] neben den Rollen des IT-Designers und des Service Design Managers vor allem der Service Level Manager von Bedeutung. Ergänzend zur ITIL® existieren weitere Rollen, die für einen funktionierenden SLM-Prozess notwendig sind. Dies sind z. B. die internen und externen Service-Lieferanten und natürlich der Kunde. Die Aufgaben und Aktivitäten der Rollen richten sich eng an den Zielen und Aktivitäten des Service Level Managements aus. Als zentrale Person im Prozess Service Level Management werden dem Service Level Manager z. B. folgende Aufgaben zugeordnet: • Änderungen an Anforderungen und Bedarfen ermitteln und berücksichtigen • Serviceanforderungen ermitteln und verstehen • Serviceanforderungen dokumentieren • SLA formulieren (inkl. Servicequalitäten) • Servicequalitäten durch OLA und Verträge absichern • Erstellung von Service-Reports sicherstellen • Servicequalitäten überwachen • Verbesserungsmaßnahmen bei Service Level Verletzungen einleiten • Messung der Servicequalitäten sicherstellen • Service Review-Treffen vorbereiten und durchführen • Leistungsfähigkeit des IT-Dienstleisters überwachen Bundesamt für Sicherheit in der Informationstechnik

13

2 Serice Level Management – Prozess zur Steuerung der Servicequalität

• Auswirkungen von Änderungen an der IT prüfen • Kundenkommunikation und Kundenbeziehung sicherstellen • Beschwerden dokumentieren und aktiv behandeln • Kundenzufriedenheit messen, analysieren und verbessern • Eskalationswege definieren und absichern

14

Bundesamt für Sicherheit in der Informationstechnik

Service Level Agreements 3

3

Service Level Agreements

3.1

Definition und Begriffsklärung

Das offizielle [ITIL Glossar] definiert das Service Level Agreement als „eine Vereinbarung zwischen einem IT-Service-Provider und einem Kunden. Das SLA beschreibt den jeweiligen ITService, dokumentiert Service-Level-Ziele und legt die Verantwortlichkeiten des IT-Service Providers und des Kunden fest. Ein einzelnes SLA kann mehrere IT-Services oder mehrere Kunden abdecken.“ Mit dieser Definition wird bereits grob umrissen, welche Inhalte in einem SLA erwartet werden. Betrachtet man die einzelnen Elemente der Begriffserklärung näher, ergeben sich jedoch weitere Differenzierungen, auf die in der Folge näher eingegangen wird. Das SLA ist eine Vereinbarung zwischen einem IT-Service Provider und einem Kunden. Der Begriff „IT-Service Provider“ lässt sich weiter unterteilen: Interner Service Provider Der aktuell in der Bundesverwaltung am häufigsten anzutreffende Provider-Typ dürfte nach wir vor der „interne Service Provider“ sein. Hiermit gemeint ist ein interner Bereich, z. B. ein IT-Referat, eine IT-Referatsgruppe oder eine IT-Abteilung, die für die eigene Behörde IT-Services erbringt. Vorteil dieser Organisationsform ist, dass die IT sehr nahe bei Ihren Kunden ist und die Bedürfnisse und Anforderungen gut kennenlernen kann. In der Folge können IT-Services stark individualisiert auf die Kunden ausgerichtet sein. Shared Service Provider Das Modell der Shared Service Provider wird in der Bundesverwaltung aktuell mit der Bildung der Dienstleistungszentren-IT umgesetzt. Ein Shared Service Provider ist eine weitestgehend eigenständige Organisationseinheit innerhalb der Bundesverwaltung, die innerhalb dieses Bereichs IT-Services erbringt. Die Bildung von Shared Service Providern ermöglicht in der Regel einen guten Leistungsvergleich mit externen Service Providern und ist vor allem bei IT-Services angezeigt, die nicht mit hohem Individualisierungsgrad und für eine größere Anzahl an Kunden vergleichbarer Qualität erbracht werden sollen. Externer Service Provider Der externe Service Provider schließlich ist bezogen auf die Bundesverwaltung die klassische privatwirtschaftliche Firma, die IT-Leistungen liefert. Ein SLA soll nun zwischen diesen Service Providern und Kunden vereinbart werden. Kunde ist hier die Person oder Stelle, die einen konkreten IT-Service erwirbt, d. h. die notwendigen Servicequalitäten und -ziele verhandelt und im Allgemeinen auch für die Lieferung bezahlt.

Bundesamt für Sicherheit in der Informationstechnik

15

3 Service Level Agreements

Vor diesem Hintergrund wird schnell deutlich, dass die Vereinbarung von SLAs vielfältiger Natur sein kann – wie in der nachstehenden Abbildung skizziert:

Kunde SLA 1

SLA 3

SLA 2

Interner Service Provider

Shared Service Provider SLA 5

Externer Service Provider SLA 6

SLA 4 Abbildung 1: SLA-Beziehungen

Als Kunde können SLAs mit allen drei Typen von Service Providern vereinbart werden (SLA 1 bis SLA 3). Eine Besonderheit hierbei stellt SLA 3 dar. Während SLA 1 und SLA 2 interne Vereinbarungen darstellen, besitzt das SLA 3 den rechtlichen Charakter eines Vertrages. Hier können inhaltlich weitergehende Regelungen getroffen werden, als dies bei den internen Vereinbarungen möglich ist (z. B. Vertragsstrafen). Auch zwischen den jeweiligen Service Providern werden SLA vereinbart. So können sowohl ein interner Service Provider als auch der Shared Service Provider über SLA die Unterstützung durch einen externen Service Provider beziehen (SLA 4 und SLA 6). Auch diese Vereinbarungen gelten juristisch als Vertrag. Schließlich kann die Beziehung zwischen den internen und den Shared Service Providern ebenfalls als SLA formuliert werden (SLA 5). So werden diese Vereinbarungen auch heute schon zwischen einzelnen DLZ-IT und internen IT-Organisationen verschiedener Kundenbehörden geschlossen (z. B. Hosting des Government Site Builders in der BIT). Das SLA beschreibt den jeweiligen IT-Service. In SLAs sollen IT-Services beschrieben werden. Der Begriff des IT-Service geht im Kontext des Service Level Managements über die reine Betrachtung technischer Komponenten hinaus. „Ein ITService besteht aus einer Kombination von Personen, Prozessen und Technologie.“ [ITIL Glossar]. Darüber hinaus soll ein IT-Service den Kunden in seinen Aufgaben unterstützen und deshalb auch aus seiner Sicht dargestellt werden. Für die Beschreibung von IT-Services in SLAs bedeutet dies, dass der Nutzen aus Kundensicht und die Funktionalität aus Nutzersicht dargestellt werden müssen. Technische Begrifflichkeiten oder Spezifikationen wie z. B. verwendete Technologien, konkrete Hardware-Produkte o. ä. sollten zu Gunsten der funktionalen Beschreibung möglichst außen vor bleiben oder auf das Notwendigste reduziert werden.

16

Bundesamt für Sicherheit in der Informationstechnik

Service Level Agreements 3

So dürfte z. B. einen Haushälter interessieren, ob er mit einem angebotenen IT-Service komfortabel Haushaltsmittel verwalten kann. Ob sein „Haushaltsservice“ dabei auf Basis einer bestimmten Datenbank installiert ist, sollte im Allgemeinen nicht von Interesse sein. Das SLA dokumentiert Service-Level-Ziele. Neben der Beschreibung von Nutzen und Funktionalität ist die Dokumentation konkreter ServiceLevel-Ziele wesentlicher Bestandteil von SLAs. Diese Service-Level-Ziele sollen in Form konkreter, messbarer und realistischer Kennzahlen gemeinsam mit den Kunden ermittelt und vereinbart werden. Klassische Beispiele für Service-Level-Ziele sind die Verfügbarkeit, die Kapazität, Sicherheits- oder Kontinuitätsanforderungen. Hierbei sollte nicht nach dem oftmals in diesem Zusammenhang propagierten Zitat von Galileo Galilei verfahren werden („Miss alles, was sich messen lässt, und mach alles messbar, was sich nicht messen lässt.“). Einige wenige, dafür aber aussagekräftige und aus Sicht des Kunden die Servicequalität tatsächlich beschreibende Kennzahlen sind maßgebend. Für diese Kennzahlen gilt natürlich, dass sie auch messbar sein müssen. Beispiele für Service-Level-Ziele werden in Kapitel 3.4 - Gliederung und Inhalte von Service Level Agreements vorgestellt. Das SLA legt die Verantwortlichkeiten des IT-Service-Providers und des Kunden fest. Als gegenseitige Vereinbarung soll in einem SLA auch klar geregelt werden, welche Rechte und Pflichten sowohl auf Seiten des Service Providers als auch auf Seiten des Kunden liegen. Die Pflichten des Service Providers werden hierbei in aller Regel schon durch die Service-Beschreibung und die Service-Level-Ziele definiert. Die Lieferung des beschriebenen Services zu den definierten Qualitätskennzahlen liegt in der Verantwortung des Providers. In Ergänzung sollte auch deutlich geregelt sein, welche Aufgaben der Kunde erfüllen sollte. Bei SLAs mit Außenwirkung ist dies in der Regel die Bezahlung des ITServices. SLAs im Innenverhältnis können darüber hinaus z. B. ergänzende Verantwortlichkeiten beschreiben. So wird bei vielen SLA zwischen den DLZ-IT und ihren Kunden wohl ein Anschluss an die „Netze des Bundes“ verpflichtend sein oder diverse Zutrittsbeschränkungen usw. Hilfreich ist es, sich gerade bei Klärung der gegenseitigen Verantwortlichkeiten bewusst zu machen, dass das Wort Agreement eher Übereinkommen und Einigkeit bedeutet und nicht „Knebelvertrag“. Ein einzelnes SLA kann mehrere IT-Services oder mehrere Kunden abdecken. Schon bei der Erstellung der SLA-Vorlagen sollte geprüft werden, in welchen Konstellationen SLAs vereinbart werden sollen. Je nach Kundenanzahl oder angebotenen Servicevarianten können unterschiedliche SLA-Strukturen entwickelt werden. Ziel ist es hier, die Komplexität in der laufenden Arbeit mit SLAs zu reduzieren. [ITIL 2007] unterscheidet im Wesentlichen drei Arten von Service Level Agreements:

Bundesamt für Sicherheit in der Informationstechnik

17

3 Service Level Agreements

Service-basiertes SLA Kunden-basiertes SLA Multi-Level SLA

Organisation Kunde Service

Abbildung 2: Strukturen von Service Level Agreements

In Service-basierten SLAs wird für jeden IT-Service ein SLA vereinbart – unabhängig von einem konkreten Kunden. Diese Art von SLAs ist besonders häufig anzutreffen bei standardisierten ITServices, die einer großen Zahl von Kunden in vergleichbarer Qualität angeboten werden. Betreibt ein IT-Service Provider z. B. einen E-Mail-Service auf einer Infrastruktur, die aber von 100 Kunden genutzt wird, wird sich die Qualität für den einzelnen Kunden des E-Mail-Services kaum unterscheiden können. Hier könnten „Standard-SLAs“ formuliert werden, die jedem Kunden angeboten werden. Kunden-basierte SLAs sind hingegen auf den einzelnen Kunden bezogen deutlich spezifischer und angepasster. Hier werden in einem SLA sämtliche IT-Services, die ein konkreter Kunde bezieht, beschrieben und vereinbart. Diese Art der SLA-Struktur ist z. B. dann sinnvoll, wenn das SLA auf Kundenseite unabhängig vom IT-Service von einer Person verantwortet und auch unterschrieben wird. Eine in der Praxis ebenfalls regelmäßig anzutreffende SLA-Struktur sind die Multi-Level-SLA. Hier werden auf verschiedenen Ebenen die jeweils zusammenfassbaren Inhalte konsolidiert. Es gilt das Motto „So allgemein wie möglich, aber so konkret wie nötig“. SLA-Inhalte, die ein komplette Organisation betreffen, werden auf dem Level der Organisation vereinbart. In der Bundesveraltung könnten dies z. B. eine weitreichende Verwaltungsvereinbarung sein, aber auch übergreifende Ansprechpartner im Sinne eines Behördenbetreuers. Auf der Ebene des Kunden werden schließlich Aspekte beschrieben, die für jeweils einen Kunden zwar spezifisch geregelt werden, jedoch unabhängig von einzelnen IT-Services sind. Hier könnten z. B. Regelungen für einzelne Abteilungen getroffen werden, die höhere Sicherheitsanforderungen an IT-Services haben, oder für Außenstellen, die andere Supportwege für alle IT-Services beschreiten können. Auf Service-Ebene werden schließlich je IT-Service spezifische Regelungen getroffen, wie z. B. konkrete Service Level oder die Zusicherung bestimmter Funktionalitäten.

18

Bundesamt für Sicherheit in der Informationstechnik

Service Level Agreements 3

3.2

Ziele von Service Level Agreements

Auch wenn die Ziele, die mit der Formulierung von Service Level Agreements verfolgt werden, im Allgemeinen dieselben Ziele sind, wie sie auch für den Prozess des Service Level Managements definiert wurden, lassen sich konkret auf die Vereinbarung bezogen weitere Ziele beschreiben. Insgesamt lässt sich sagen, dass mit der Vereinbarung und dauernden Pflege von Service Level Agreements Transparenz über Kosten, Erwartungen und Leistungen erzeugt wird, die in der Folge als Kommunikationsgrundlage für die dauernde Verbesserung der Service-Qualitäten, der Steuerung von IT-Systemen und der Steigerung der Wirtschaftlichkeit dient. Den Ausführungen von Thomas Berger [SLA-Dissertation] folgend lassen sich je nach Betrachtungsfokus Ziele im Interesse des IT-Dienstleisters, Ziele im Interesse des Kunden oder beiderseitig zu verfolgende Ziele konkretisieren:

Abbildung 3: Ziele des Einsatzes von SLAs [SLA-Dissertation]

Ziele im Interesse des Kunden: 1.)

Erzielung von Kostentransparenz: Sofern Kosten zwischen dem IT-Dienstleister und dem Kunden verrechnet werden, was vor allem bei internen IT-Dienstleistern der Öffentlichen Verwaltung noch nicht die Regel ist, schaffen SLAs ein hohes Maß an Kostentransparenz. Hierdurch werden den Kunden Preisvergleiche ermöglicht.

2.)

Förderung eines verantwortungsvollen Umgangs mit IT-Dienstleistungen: Durch Kostentransparenz soll auch ein Verständnis für den Wert der IT-Services geschaffen werden. Der Kunde erfährt unmittelbar, welche Anforderungen zu welchen Kosten realisiert werden. So ist es möglich, die wirtschaftliche Notwendigkeit von Anforderungen zu bewerten und diese gegebenenfalls zu korrigieren.

Bundesamt für Sicherheit in der Informationstechnik

19

3 Service Level Agreements

3.)

Verbesserung von Einflussmöglichkeiten auf die IT-Kosten: Bei der Dokumentation von Kosten müssen IT-Dienstleister damit rechnen, diese dem Kunden gegenüber zu rechtfertigen. Generell erhält der Kunde durch SLAs mehr Möglichkeiten, die Entstehung der Kosten zu verstehen und zu beeinflussen.

4.)

Reduktion der IT-Kosten: Durch Leistungs- und Kostentransparenz wird anhand von Kosten-Nutzen-Analysen schnell deutlich, welche vielleicht nicht notwendigen Forderungen künftig nicht mehr bedient werden müssen.

Ziele im Interesse des Dienstleisters: 1.)

Fixierung von Kundenerwartungen: Durch die Ermittlung und schriftliche Fixierung von Kundenerwartungen ist es möglich, aktiv mit diesen umzugehen und die Leistungserbringung in der IT entsprechend zu steuern.

2.)

Schaffung von Planungssicherheit und Investitionsschutz: In einem SLA fixierte Anforderungen von Kunden bezüglich Funktionalitäten von IT-Services, benötigter Kapazität, Verfügbarkeit und Sicherheit ermöglichen IT-Dienstleistern ein hohes Maß an Planungssicherheit und vergrößern die Steuerungsmöglichkeiten der IT-Infrastruktur.

3.)

Schaffung einer Grundlage für die Rechtfertigung von IT-Investitionen: Vor allem bei internen IT-Dienstleistern können SLAs und die hier vereinbarten Service Level Ziele als Begründung für Investitionen dienen.

Ziele im Interesse des Kunden: 1.)

Erzielung von Kostentransparenz: Sofern Kosten zwischen dem IT-Dienstleister und dem Kunden verrechnet werden, was vor allem bei internen IT-Dienstleistern der Öffentlichen Verwaltung noch nicht die Regel ist, schaffen SLAs ein hohes Maß an Kostentransparenz. Hierdurch werden den Kunden Preisvergleiche ermöglicht.

2.)

Förderung eines verantwortungsvollen Umgangs mit IT-Dienstleistungen: Durch Kostentransparenz soll auch ein Verständnis für den Wert der IT-Services geschaffen werden. Der Kunde erfährt unmittelbar, welche Anforderungen zu welchen Kosten realisiert werden. So ist es möglich, die wirtschaftliche Notwendigkeit von Anforderungen zu bewerten und diese gegebenenfalls zu korrigieren.

3.)

Verbesserung von Einflussmöglichkeiten auf die IT-Kosten: Bei der Dokumentation von Kosten müssen IT-Dienstleister damit rechnen, diese dem Kunden gegenüber zu rechtfertigen. Generell erhält der Kunde durch SLAs mehr Möglichkeiten, die Entstehung der Kosten zu verstehen und zu beeinflussen.

4.)

Reduktion der IT-Kosten: Durch Leistungs- und Kostentransparenz wird anhand von Kosten-Nutzen-Analysen schnell deutlich, welche vielleicht nicht notwendigen Forderungen künftig nicht mehr bedient werden müssen.

20

Bundesamt für Sicherheit in der Informationstechnik

Service Level Agreements 3

3.3

Herausforderungen und Voraussetzungen

In der Entwicklung und Durchführung des Service Level Managements gibt es sicher mannigfaltige Erfolgsfaktoren zu realisieren und Herausforderungen zu meistern. Bezogen auf die Steuerung von Servicequalitäten durch Service Level Agreements sind im Folgenden fünf wesentliche Faktoren aufgeführt, die vorliegen sollten, damit SLAs ihre beschriebene Wirkung erreichen können.

3.3.1 Akzeptanz von Service Level Agreements Der Begriff Service Level Agreement ist im Laufe der letzten Jahre auch in der Öffentlichen Verwaltung zunehmend gebräuchlich. In immer mehr Behörden werden SLAs mit Dienstleistungszentren oder externen Lieferanten vereinbart, teilweise existieren bereits interne SLAs. Die Intention, die hinter der zunehmenden Nutzung von SLAs steht, deckt sich hierbei sicher häufig mit der eingangs beschriebenen steigenden Bedeutung und Kritikalität von IT-Services für die Funktionsfähigkeit der Verwaltung. Trotzdem sind SLM-Initiativen gerade auf Kundenseite nicht immer gern gesehen. Eine Ursache hierfür liefert die aus Sicht der IT formulierte Frage: Warum sollten unsere Kunden SLAs wollen? Aus Kundensicht sind in SLAs zugesicherte Servicequalitäten sicher immer dann sinnvoll, wenn Leistungen in der Vergangenheit häufig nicht in erwarteter Form erbracht wurden, und sich durch SLAs die Verhandlungs- und Forderungsposition der Kunden stärkt. Auf der anderen Seite wird durch die klare Regelung in einem SLA aber genau definiert, welche Leistungen Kunden einfordern können und welche Servicekomponenten nicht Bestandteil einer Lieferung sind. Je nach herrschender Kultur einer Behörde kann ein SLA aus dem Blickwinkel des Kunden also auch Einschränkungen mit sich bringen. Während bisher freie Forderungen aufgestellt werden konnten, wird diese Freiheit durch definierte und beschriebene IT-Services auf den SLAInhalt beschränkt. Auch im Buch „ ITIL® Version 3 - Continual Service Improvement“ [ITIL-CSI] wird diese Problematik beschrieben. Während sich viele SLM-Aktivitäten auf die Erstellung und Vereinbarung expliziter, d. h. formalisierter und dokumentierter SLAs beschränken, existieren auch sogenannte implizite und psychologische SLAs. Ein implizites SLA bildet sich auf Kundenseite auf Basis von Erfahrungen vergangener Servicelieferungen. Ist es z. B. in einer Behörde üblich, neue Software über einen Anruf im Service Desk problemlos installiert zu bekommen, erwarten Kunden vergleichbare Regelungen auch unabhängig von einem dokumentierten SLA mit etwaigen lizenzrechtlichen Bestimmungen und Verfahrenswegen. In eine ähnliche Richtung gehen die psychologischen SLAs. Hier hat die IT-Organisation durch Aussagen wie „Unser Service Desk löst alle Probleme – ein Anruf genügt!“ bei Kunden schon häufig eine bestimmte Assoziation geschaffen, die konkrete Erwartungen an die Servicequalität erzeugt.

Bundesamt für Sicherheit in der Informationstechnik

21

3 Service Level Agreements

Wird vor diesem Hintergrund jetzt ein formales SLA erstellt, welche diese aus Kundensicht bestehende Regelungen relativiert, definiert oder einschränkt, geht in aller Regel die Akzeptanz für die dokumentierten SLA verloren. Es ist daher wichtig, das SLA als Bestandteil eines umfassenderen SLM-Prozesses zu sehen, der im Kern die Pflege der Kunden-Dienstleister-Beziehung besitzt. SLAs sollten nicht als Selbstzweck vereinbart werden, sondern als lebendige Steuerungshilfe zur Sicherstellung einer angemessenen, notwendigen und wirtschaftlichen Servicequalität verstanden werden.

3.3.2 Absicherung von Leistungszusagen Die größte Herausforderung im SLM-Prozess ist es, die in den SLA gegenüber den Kunden vereinbarten Qualitätsparameter in der eigenen IT-Organisation und gegenüber externen Lieferanten abzusichern. Hierzu ist es notwendig, die tatsächliche Leistungsfähigkeit der eigenen IT-Organisation und auch der Lieferanten zu kennen und mit diesen Vereinbarungen zu treffen, die den SLA-Zusagen entsprechen. Gerade bei Zusicherungen aus der eigenen IT-Organisation sind in der Praxis häufig Hürden zu überwinden, die u. a. in der jeweiligen Behördenkultur verankert liegen. Aber auch gegenüber externen Lieferanten ist es nicht einfach, unter Beteiligung der Beschaffungsstellen, Berücksichtigung bestehender Rahmenverträge und Beachtung weitergehender rechtlichen Restriktionen den notwendigen Einfluss auszuüben. Generell besteht in der Verwaltung die große Gefahr, dass ohne diese Leistungsabsicherungen durch unterstützende Vereinbarungen zwar ein Dokument verfasst wird, welches mit dem Titel „Service Level Agreement“ versehen ist, im eigentlichen Sinne aber die dort beschriebenen Leistungen nicht garantieren kann.

3.3.3 Wahrnehmung der Kundenrolle Das Service Level Management geht von einer vorhandenen und auszubauenden KundeDienstleister-Beziehung aus. Im Allgemeinen ist diese Beziehung dadurch geprägt, dass ein Kunde gegenüber dem IT-Dienstleister Leistungen fordert, der Dienstleister diese Leistung dem Kundenwunsch entsprechend erbringt und der Kunde im Anschluss für diese Leistung zahlt (zur Verdeutlichung denken Sie vielleicht an einen Frisörbesuch...) In der Bundesverwaltung gestaltet sich diese Kunde-Dienstleister-Beziehung häufig anders. Hier definiert der Service Provider in der Regel, welche Leistungen ein Kunde erhält (z. B. PCAusstattung oder Dokumentenmanagement-Tool). Die Haushaltsmittel besitzt in aller Regel nicht der Kunde, sondern der Dienstleister (IT-Haushalte). Weder Kunde noch Service Provider sind in der Formulierung von Anforderungen und deren Umsetzung frei, da politische oder ministerielle Einflüsse beachtet werden müssen (z. B. Vorgabe von Standards oder konkrete Erlasse). Vor diesem Hintergrund hat sich über den Zeitablauf eine Konstellation zwischen Fachbereichen und IT-Dienstleistern gebildet, die einem klassischen „Über-Unter-Ordnungsverhältnis“ näher kommt, als der im SLM notwendigen Kunde-Dienstleister-Beziehung. Statt Forderungen zu formulieren, wird häufig eher eine IT-Leistung „beantragt“, die im günstigsten Fall „positiv beschieden“ wird. 22

Bundesamt für Sicherheit in der Informationstechnik

Service Level Agreements 3

Vor diesem Hintergrund ist es bei der Umsetzung von SLM und SLAs für einen Kunden sehr schwierig, seine angedachte Rolle auch tatsächlich wahrzunehmen. In aller Regel führt ein SLMProzess hier zu einer langfristig anzulegenden kulturellen Änderung und kann zu Beginn der Aktivitäten nicht als gegeben vorausgesetzt werden. Dies sollte möglichst frühzeitig transparent und mit Maßnahmen der Organisationsentwicklung bzw. des organisatorischen Change Managements gesteuert werden.

3.3.4 Besetzung des Service Level Managers Service Level Agreements sollten möglichst in einer Sprache verfasst werden, die es dem Kunden ermöglicht, die Erfüllung seiner Anforderungen an den IT-Service zu erkennen. Dies bedeutet, dass der IT-Dienstleister in der Lage sein muss, die technische Sicht zu verlassen und die Leistungen im SLA aus Sicht des Kunden zu formulieren. Technische Details, komplizierte Leistungsabgrenzungen oder technologische Restriktionen sollten vermieden werden. Es wird verlangt, dass der auf Seiten des IT-Dienstleisters für die SLA-Vereinbarung verantwortliche Service Level Manager die Anforderungen der Kundenseite kennt und die Bedürfnisse in der Aufgabenerfüllung der Fachbereiche versteht. Auf der anderen Seite muss sichergestellt sein, dass in den SLAs nur Vereinbarungen getroffen werden, die technisch realisierbar sind. Insofern wird vom Service Level Manager nicht nur ein hohes fachliches Verständnis verlangt, sondern zudem grundlegende technische Expertise. Mit dieser Qualifikationsanforderung ist die Besetzung der Rolle des Service Level Managers nicht einfach – aber für einen funktionierenden SLM-Prozess essenziell.

3.3.5 Klare Verantwortlichkeiten In einem SLA werden Leistungskennzahlen zwischen einem IT-Service Provider und einem Kunden dokumentiert. Ziel des SLA ist es, eine übereinstimmende Vereinbarung über die zu erbringende Leistungsqualität zu erreichen. In der Praxis lässt sich allerdings häufig beobachten, dass hier getroffene Vereinbarungen durch weitere Linienfunktion in der Organisation und politische Einflüsse übersteuert werden. Was in gewissem Maße sicher toleriert und als gegeben angesehen werden muss, kann bei übermäßigem Auftreten zu einer Lähmung des SLM-Prozesses und der Unwirksamkeit der SLAs führen. Es ist daher notwendig, zu Beginn der SLM-Aktivitäten die herrschenden Rahmenbedingungen zu klären und diese in der Ausgestaltung des SLA-Managements zu berücksichtigen.

3.4

Gliederung und Inhalte von Service Level Agreements

3.4.1 Einleitung Aufgrund der vielfältigen Einsatzgebiete von Service Level Agreements ist es sicher nicht möglich, ein konkretes SLA-Template zu entwerfen, welches in allen Fällen als Vorlage universell einsetzbar

Bundesamt für Sicherheit in der Informationstechnik

23

3 Service Level Agreements

ist. Dennoch können aus den bisher beschriebenen Elementen, ergänzender Literatur und praktischen Erfahrungen einige wesentliche Bausteine für SLAs zusammengefasst und ein Gliederungsvorschlag dargestellt werden. Für die folgende Darstellung wurden im Wesentlichen zwei externe Quellen herangezogen: Zum einen hat Thomas Berger in seiner Dissertation unter dem Titel „Konzeption und Management von Service Level Agreements für IT-Dienstleistungen“ [SLA-Dissertation] wesentliche Elemente von Service Level Agreements ermittelt und beschrieben sowie hieraus einen Gliederungsvorschlag für SLAs erarbeitet. Zum anderen wurde durch diverse Autoren im Buch „Service Level Management in der Öffentlichen Verwaltung“ [SLM ÖV] eine „SLA-Mustervereinbarung“ formuliert und veröffentlicht, die aus der praktischen Erfahrung im SLM der Öffentlichen Verwaltung hervorgeht. Auch wenn in dieser Studie diese beide Quellen natürlich nicht vollständig wiedergegeben werden, soll im Folgenden auf ihrer Basis ergänzt um praktische Erfahrungen – vor allem im Umfeld der Öffentlichen Verwaltung – eine möglichst konsistente Darstellung typischer Inhalte von Service Level Agreements formuliert und mit Beispielen ausgestaltet werden.

24

Bundesamt für Sicherheit in der Informationstechnik

Service Level Agreements 3

3.4.2 Aufbau und Strukturierung - Gliederungsvorschlag Folgende Übersicht kann als Grundlage für die Ausgestaltung von SLA-Templates dienen: 1. Einleitung/Präambel 1.1 Gegenstand der Vereinbarung 1.2 Ziele der Vereinbarung 1.3 Versionierung des SLA 2. Grundlagen der Vereinbarung 2.1 Partner 2.2 Geltungsbereich 2.3 Inkrafttreten, Laufzeit und Kündigung 2.4 Pflichten der Partner 2.5 Vertraulichkeit, Geheimhaltung und Veröffentlichung 3. Beschreibung des IT-Service 3.1 Bezeichnung und Kurzbeschreibung 3.2 Nutzen für den Kunden 3.3 Anwenderfunktionalitäten 3.4 Service-Qualitäten 3.5 Servicezeiten und Support 3.6 Bedingungen der Servicenutzung 3.7 Kosten und Vergütung 4. Kommunikation und Berichtswesen 4.1 Service Level Berichte 4.2 Service Review-Treffen 4.3 Regelungen zur Änderung der Vereinbarung 4.4 Konfliktlösung und Eskalationswege 4.5 Kontaktdaten/Ansprechpartner 5. Juristischer Gegenstand der Vereinbarung 5.1 Gerichtsstand 5.2 Haftung und Gewährleistung 5.3 Schadenersatz 5.4 Anwendbares Recht 5.5 Teilnichtigkeit von Regelungen 6. Unterschriften 7. Anhänge

Bundesamt für Sicherheit in der Informationstechnik

25

3 Service Level Agreements

Die einzelnen Aspekte diese Gliederung werden im Folgenden näher vorgestellt. Der Schwerpunkt liegt hierbei auf Kapitel 3 – Beschreibung eines IT-Services. Einleitung/Präambel Vor dem eigentlichen Beginn eines SLAs sollten einige übergreifende Aspekte der Vereinbarung in einer Einleitung bzw. Präambel beschrieben werden. Hierzu zählen der Gegenstand des SLAs und eine Darstellung des Zwecks der Vereinbarung. Hier könnten z. B. die Ziele beschrieben werden, die zur Vereinbarung des SLA mit den beteiligten Partnern geführt haben. Vor dem Hintergrund eines „lebenden Dokuments“ sollte zudem eine Versionsübersicht eingeführt werden, aus welcher künftig die verschiedenen Änderungen am SLA nachvollzogen werden können. Die Beschreibung dieses Aspektes ist sowohl bei Vereinbarungen zwischen internen Stellen als auch bei Verträgen mit externen IT-Dienstleistern sinnvoll. Grundlagen der Vereinbarung Bevor der eigentliche IT-Service im folgenden Kapitel der SLA-Gliederung beschrieben wird, werden in dem Kapitel „Grundlagen der Vereinbarung“ service-übergreifende Rahmenbedingungen für die Erbringung von IT-Services beschrieben. Diese Strukturierung hat den Vorteil, dass neben den service- und kunden-basierten SLAs auch Multi-Level SLAs abgebildet werden können, ohne das Template wesentlich zu verändern. Als „Partner der Vereinbarung“ sollten in diesem Abschnitt neben den beteiligten Organisationen (z. B.: Kundenorganisation und IT-Dienstleister) auch konkrete Personen in Ihren jeweiligen Rollen benannt werden. Als „Geltungsbereich“ können hier organisatorische oder geographische Aspekte dargestellt werden, die die Serviceerbringung begrenzen bzw. beschreiben können. Des weiteren sollten hier Regelungen zum Inkrafttreten des SLA, zur Laufzeit und zu den beiderseitigen Kündigungsmöglichkeiten aufgeführt werden. Auch Pflichten der Partner der Vereinbarung sollten hier aufgeführt werden. Schließlich können in diesem Abschnitt Bestimmungen zum Umgang mit den Inhalten des SLA getroffen werden. Dies ist insbesondere dann wichtig, wenn einzelne Servicebestandteile von nachgelagerten Organisationseinheiten oder externen Lieferanten erbracht werden. Hier könnten z. B. mit Verweis auf das SLA entsprechende OLAs oder unterstützende Verträge vereinbart werden. Die „Grundlagen der Vereinbarung“ sind bei allen Arten von SLA relevant und können Bestandteil des SLA sein. Beschreibung des IT-Services Den Kern eines SLAs stellen IT-Services dar. Umfasst ein SLA mehrere IT-Services, wiederholt sich die Struktur dieses Abschnitts entsprechend der Anzahl der vereinbarten IT-Services. Die Beschreibung von IT-Services erweist sich in der Praxis häufig als problematisch und große Herausforderung – vor allem interne IT-Dienstleister sind hier häufig stark gefordert. Während bisher zwar mehr oder minder bekannte Qualitätserwartungen der Kunden an den IT-Dienstleister vorlagen, die in der Regel „auf Zuruf“ bedient wurden, wird nun verlangt diesen Erwartungen messund nachvollziehbare Leistungen gegenüberzustellen. Für den IT-Dienstleister bedeutet dieser Schritt, dass er seine Leistungen aktiv im Sinne der Erreichung der Vereinbarung steuern können muss. Hierfür müssen Leistungen und erreichbare Qualitäten bekannt und beschreibbar sein.

26

Bundesamt für Sicherheit in der Informationstechnik

Service Level Agreements 3

Das im Folgenden vorgestellte Raster zur Beschreibung eines IT-Services hat sich so oder in ähnlicher Form in der Praxis als Leitfaden bewährt, um gegenüber Kunden eine Leistungszusage zu formulieren. Bezeichnung und Kurzbeschreibung Der IT-Services sollte zunächst prägnant und eindeutig bezeichnet werden. Hierbei ist vor allem darauf Wert zu legen, dass den Kunden ein direkter Rückschluss auf die Leistungsinhalte möglich wird. Unter der Bezeichnung „E-Mail-Service“ kann sicher ein Großteil potentieller ServiceEmpfänger Inhalte erkennen, unter „ADS/LDAP-Service“ eher die Techniker. Neben der Bezeichnung sollte der IT-Service kurz verbal beschrieben werden, um die Einordnung und das Verständnis über den Serviceinhalt schon zu Beginn der Servicebeschreibung für den Kunden zu festigen. Nutzen für den Kunden Im IT-Servicemanagement wird die Rolle des Kunden von der Rolle des Anwenders unterschieden. Während der Kunde bezogen auf das SLA die Person ist, welche das SLA unterzeichnet, Anforderungen formuliert und – sofern vereinbart – die Kosten des IT-Services trägt, ist der Anwender der Nutzer des vereinbarten IT-Services. In einem SLA sollte nun aus Sicht des Kunden der Nutzen beschrieben werden, den der IT-Service mit sich bringt. Im Beispiel der E-Mail kann dies die Beschleunigung von Kommunikationswegen, die Senkung von Kosten im Vergleich zum Brief oder ähnliches sein. Es ist häufig ausreichend, diesen Nutzen in wenigen, aber prägnanten und verständlichen Aussagen zu beschreiben. Die Erreichung des hier formulierten Nutzens wird bei der Bewertung von Leistungen Maßstab für den Kunden sein. Wird hier z. B. vor Einführung und Lieferung eines Dokumentenmanagementsystems als Nutzen beschrieben, dass Dokumente jederzeit an jedem Ort elektronisch verfügbar sind, sollte dieser Nutzen auch nachweisbar eintreffen. Anwenderfunktionalitäten Analog der Beschreibung des Kundennutzens sollten in einem SLA in ähnlich prägnanter Form Funktionen dargestellt werden, die Anwender nutzen können. Im Beispiel der E-Mail wären dies etwa das Versenden und Empfangen von E-Mails, die Übermittlung von Lese- und Versandinformationen, die Öffnung von Dateianlagen usw. Durch die Beschreibung von Funktionalitäten eines IT-Services erhält der Kunde die Möglichkeit zu prüfen, ob der IT-Service für seine Zwecke angemessen ist und seinen Bedarf grundsätzlich abdecken kann. Service-Qualitäten Die Beschreibung von Funktionen eines IT-Services ist nicht ausreichend, um Kunden tatsächlich zu Gewährleisten, dass Ihren Anforderungen an den IT-Service erfüllt werden. Es gilt daher, Nutzen und Funktionalitäten konkret durch messbare Qualitätszusagen zu untermauern und über diese auch zu berichten.

Bundesamt für Sicherheit in der Informationstechnik

27

3 Service Level Agreements

In der Praxis gibt es sicher eine Vielzahl von Parametern, die die Service-Qualitäten beschreiben. In einem SLA sollte jedoch weniger eine hohe Anzahl an Qualitätsparametern definiert werden als vielmehr einige wenige aber aussagekräftige und tatsächlich messbare Kennzahlen. Beispiel: Verfügbarkeit/Antwortzeit Die Angabe einer prozentualen Verfügbarkeit ist in SLAs häufig der erste Ansatz. Bei näherem Hinsehen erkennt man jedoch, dass die Kennzahl „95 % Verfügbarkeit“ aus Anwendersicht wenig aussagekräftig ist. Hier hat sich eher bewährt, die Antwortzeit zu beschreiben. Hiermit ist die Zeitspanne definiert, die der Anwender zwischen dem Absenden eines Bildschirmbefehls und der erwarteten Antwort wahrnimmt. Da die Antwortzeit in der Praxis häufig recht schwierig zu messen ist, schlägt [ITIL 2007] vor, in den SLAs folgenden Satz aufzunehmen: „Der durch dieses SLA abgedeckte Service ist ausgelegt auf schnelle Antwortzeiten, so dass keine signifikanten Verzögerungen auftreten sollten. Wenn die Antwortzeit mehr als Y Minuten/mehr als X Sekunden beträgt, sollte dies sofort dem Service Desk gemeldet werden.“ Die Kunst ist es natürlich nun, für die benannten x- und y-Werte je nach Anwendungsfall akzeptable Grenzwerte zu definieren. Darüber hinaus sollten Verfügbarkeiten bzw. Antwortzeiten immer auch im Kontext der Servicezeiten und in verschiedenen Stufen beschrieben werden. Ist die Servicezeit z. B. unabhängig von Tageszeiten oder Wochentagen durchgängig definiert, könnte man die Verfügbarkeit nach folgendem Muster beschreiben: • Antwortzeit weniger als 1 Sekunde für 90 % der Anfragen • Antwortzeit weniger als 3 Sekunden für 95 % der Anfragen • Antwortzeit mehr als 3 Sekunden für maximal 5 % der Anfragen

Diese Zeiten sollten dann aus dem Blickwinkel des Anwenders gemessen und auch berichtet werden. In Ergänzung hierzu lässt sich zudem die maximale Ausfallzeit (z. B. zwei aufeinanderfolgende Stunden an einem Werktag) und die maximale Anzahl der Ausfälle, z. B. maximal sechs Ausfallzeiten pro Jahr) definieren. Neben der Antwortzeit lassen sich ähnliche Parameter in den Bereichen Sicherheit und Kapazität sowie Katastrophen- und Notfallmanagement definieren. Hier werden dann Parameter wie z. B. Durchlaufzeiten, Ausfallsicherheit, Nutzlastwerte, Kapazitäten wie Nutzeranzahl/Speicherlast, Sessionzahlen, Service-Kontinuität, Datensicherungszyklen etc. beschrieben. Servicezeiten und Support In diesem Abschnitt soll beschrieben werden, zu welchen Zeiten Anwender den IT-Service nutzten können. Die auch als Servicezeit beschriebene Kennzahl bezeichnet den Zeitraum, in dem die vereinbarten Service-Qualitäten garantiert werden können. Aus Kundensicht können hier besonders kritische Servicezeiten (z. B. Jahresabschluss im Haushalt) gesondert aufgeführt werden.

28

Bundesamt für Sicherheit in der Informationstechnik

Service Level Agreements 3

Neben den Servicezeiten soll auch das Unterstützungsangebot durch den IT-Dienstleister beschrieben werden. Hierzu zählen z. B. Leistungen eines Service- oder User Help Desks, Vor-OrtService, Fernwartung usw. Werden einige dieser Leistungen nur zu bestimmten Zeiten erbracht, sollte diese als Supportzeit ebenfalls beschrieben werden. Für jede der Supportleistungen lassen sich wiederum messbare Qualitätsparameter wie z. B. die Erreichbarkeit des Service Desks, die Reaktionszeit oder die Bearbeitungsdauer von Störungen mit Angabe einer Erstlösungsquote definieren. Bedingungen der Servicenutzung Im Abschnitt „Bedingungen der Servicenutzung“ lassen sich Voraussetzungen dokumentieren, die in aller Regel der Kunde erfüllen muss, damit der Service nutzbar ist. Beispiele hierfür sind der Anschluss an ein bestimmtes Netz (z. B. Netze des Bundes) oder die organisatorische Sicherstellung, dass nur Nutzer mit einer bestimmten Zertifizierung ein Verfahren nutzen können. Auch wenn der IT-Service nur an bestimmten Orten genutzt werden kann, sollte die Beschreibung dieser Einschränkungen hier erfolgen. Kosten und Vergütung Sofern eine Kostenverrechnung vereinbart wurde sollten an dieser Stelle Details über die Vergütung und Abrechnung beschrieben werden. Hierzu zählen z. B. das Verrechnungspreismodell und der Verrechnungspreis. Kommunikation und Berichtswesen Der Erfolg und Nutzen des Service Level Management steht und fällt mit einem funktionierenden Kommunikations- und Berichtswesen. Aus diesem Grund sollte neben der Servicebeschreibung in allen Varianten eines SLA besonderer Wert auf die Beschreibung dieses Bereichs gelegt werden. Zu den hier aufzuführenden Informationen zählen die Kontaktdaten des IT-Dienstleisters und des Kunden ebenso, wie die Darstellung von Eskalationswegen und die Beschreibung von Konfliktlösungen. Des weiteren wird in diesem Abschnitt des SLA genau dargelegt, in welchem Zyklus welchen Personen in welcher Form über die erbrachten IT-Services berichtet wird. Grundlage für diese Service Level Berichte sind die in der Servicebeschreibung formulierten Zusagen hinsichtlich Funktionalität, Nutzen und Qualität. Die Berichte sollten wie auch das SLA selber in einer möglichst nicht-technischen Sprache verfasst und einfach verständlich sein. Auch sollten hier Zyklus, Ablauf und Teilnehmerkreis der regelmäßigen „Review Meetings“ beschrieben werden. In Ergänzung hierzu kann auch weitergehend beschrieben werden, wie mit Serviceverbesserungen oder auch Änderungen der Anforderungen von Kunden verfahren wird. Juristischer Gegenstand der Vereinbarung Dieser Abschnitt ist in erster Linie relevant für Vereinbarungen mit externen IT-Dienstleistern. Hier wird aus einer „Servicevereinbarung“ ein „Servicevertrag“, in welchem juristische Aspekte wie Gerichtsstand, Haftungsfragen, Schadenersatzregelungen usw. geklärt werden.

Bundesamt für Sicherheit in der Informationstechnik

29

3 Service Level Agreements

Unterschriften Durch die Unterzeichnung des SLAs wird auch bei internen Vereinbarungen der bindende Charakter des „Vertrages“ deutlich. Auch ohne juristische Auswirkungen bei internen Vereinbarungen unterstreichen die Unterschriften die hohe Bedeutung des SLA für den Kunden und auf Seiten des Dienstleisters die Bestrebung, die formulierten Ziele zu erfüllen. Anhänge Als Anhang zu einem SLA können z. B. umfangreiche Beschreibungen des IT-Services, größere Kontaktlisten oder Lizenzerläuterungen dienen. Auch ist es üblich im Anhang ein Glossar sowie ein Abkürzungsverzeichnis zu pflegen.

30

Bundesamt für Sicherheit in der Informationstechnik

Grundlagen von Protection Level Agreements 4

4

Grundlagen von Protection Level Agreements

4.1

Ausgangslage

Sicherheitsanforderungen an die IT rücken in den letzten Jahren zunehmend in das Sichtfeld des Managements und werden im Risiko-Management der Organisation verankert. Dabei haben sich Standards etabliert, die den Aufbau eines Informationssicherheitsmanagementsystems (ISMS) unterstützen und vergleichbar machen. Im öffentlichen Bereich und in Deutschland allgemein ist dies insbesondere ISO 27001 auf Basis von IT-Grundschutz. Praktisch keine Organisation kann heutzutage eine komplett „hausgemachte“ IT vorweisen. Das Outsourcing der kompletten IT-Aktivitäten einer Organisation insgesamt ist dabei in den Hintergrund getreten, der Fokus liegt entweder auf dem ausgelagerten Betrieb von Standard-ITKomponenten oder von einzelnen Anwendungen bzw. bestimmten Technologien. Im Bereich der Service-Anforderungen an solche Dienstleistungen hat sich der Umgang mit Outsourcing-Dienstleistern wesentlich professionalisiert – die Notwendigkeit einer geregelten Dienstleistersteuerung und die Messbarkeit von Dienstleistungen haben in Form des Service-LevelManagements Eingang in die Unternehmenskultur gefunden. Die Ausweitung des Sicherheitsmanagements auf die ausgelagerten Teile der IT wird dabei bisher nur in Ansätzen betrachtet und ist in der Realität oft schwierig und mühsam umzusetzen. Die ITGrundschutz-Kataloge [Grundsch 2009] sind dafür ein gutes Beispiel: Für den Baustein „Outsourcing“ wird als Mindestanforderung die Einhaltung von IT-Grundschutz durch den Dienstleister gefordert, für darüber hinaus gehende Fragen wird es deutlich schwieriger. Wenn eine Zertifizierung nicht gefordert ist, wie überprüfe ich dann die Einhaltung? Wie kann ich dies im Vertrag sicher verankern? Was soll ein gemeinsames Sicherheitskonzept umfassen? Die einfache Kontrollfrage „Sind alle IT-Sicherheitskonzepte gegeneinander abgestimmt und harmonieren miteinander?“ (Maßnahme M 2.254 [Grundsch 2009]) ist in der Praxis oft schwer zu beantworten. Die größten Schwierigkeiten bereiten dabei die gerade bei standardisierten Dienstleistungen auftretenden tiefen Ketten von Subauftragnehmern. Das folgende Beispiel stammt aus der Praxis und soll die Thematik verständlich machen: Ein Unternehmen möchte einen als Web Service implementierten Dienst zum Datenaustausch mit Außendienstmitarbeitern in Anspruch nehmen, der hohe Vertraulichkeitsanforderungen erfüllt. Der Anwendungsanbieter betreibt nur die Anwendung selbst; die Systeme (Betriebssystem) dafür betreibt ein Hosting-Unternehmen, das die Hardware extern warten lässt und bei einem Housing-Provider1 in dessen RZ unterbringt. Datenspeicherplatz mit integriertem Backup wird wiederum auf einem in demselben RZ von einem Dritten betriebenem SAN-System angemietet, das im Multi-Mandantenbetrieb läuft. Letztendlich landen die Daten auf dessen Festplatten. Wie bei solchen Systemen üblich, wird die Hardware direkt vom Hersteller gewartet – dafür besitzt das System auch einen Wartungszugang. Die Frage, welche Personen nun potenziell Zugriff auf diese Daten haben, ist zumindest unübersichtlich. Im o. g. Beispiel lassen sich noch weitere Beteiligte ausmachen: 1 Auch als Co-Location oder Server-Homing bezeichnet. Bundesamt für Sicherheit in der Informationstechnik

31

4 Grundlagen von Protection Level Agreements

- Telekommunikationsbetreiber (Kommunikation zwischen den Komponenten) - Aktenvernichtungsdienstleister (Backup-Bänder, defekte Festplatten) - Transportunternehmen (Datenträger)

Diese Situation beschränkt sich nicht nur auf Unternehmen der Wirtschaft, auch wenn sie dort heute häufiger und stärker ausgeprägt ist als in anderen Organisationen. In der Bundesverwaltung könnte ein ähnliches Szenario wie folgt aussehen: Eine Behörde hat den Betrieb der SAP-R/3- bzw. MACH-M1-Anwendungen an ein DLZ des Bundes abgegeben. Dieses bedient sich in Wartungs- und Supportfällen häufig externen Dienstleistern, sowohl für die Software als auch für die Hardware: Die Softwaredienstleister können sich remote auf entsprechende Server aufschalten und die Anwendung warten bzw. Störungen beheben. Für die Hardware hat das DLZ direkt mit dem Hersteller einen SupportVertrag abgeschlossen. Um Support vor Ort leisten zu können, hat dieser Hersteller wiederum Vereinbarungen mit weiteren Subauftragnehmern getroffen, die im Bedarfsfall direkten Zugang zur Hardware erhalten. In vielen Fällen, z. B. bei den erwähnten Speichersubsystemen, gibt es keine wirtschaftlichen Alternativen zum externen Support. Der Versuch der adäquaten Absicherung führt in der Praxis oft zur Ausblendung problematischer Aspekte aus der Sicherheitsbetrachtung oder zum Gegenteil, der Überabsicherung unter oft nicht angemessenen Kosten. In den genannten Praxisszenarien geht es also nicht um die 1-zu-1-Beziehung zwischen einem Anbieter und einem Nutzer, sondern um ein komplexes Geflecht von Leistungsbeziehungen mit einer Vielzahl von beteiligten Stellen. Dies verdeutlicht, dass eine adäquate Absicherung auch möglich sein muss, ohne dass alle beteiligten Organisationen über ein zertifiziertes ISMS, etwa auf Basis von IT-Grundschutz, verfügen. Dennoch ist es erforderlich, dass gewisse Anforderungen erfüllt werden. In der Praxis ergeben sich hieraus zwei grundsätzliche Fragen: 1. Was sind meine Sicherheitsanforderungen, und wie kommuniziere ich diese meinem Dienstleister? 2. Wie können die Sicherheitsanforderungen in einer immer tiefer werdenden Kette von Subauftragnehmern eingehalten werden?

4.2

Qualitity of Protection und Protection Level Agreements

Diese Studie beschreibt einen Ansatz zur Beantwortung der aufgeworfenen Fragestellungen durch Protection Level Agreements (PLAs). PLAs sind ein vergleichsweise neues Konzept, das wissenschaftlich erst seit wenigen Jahren diskutiert wird, und soll, analog zu SLAs, die Vereinbarung des Schutzniveaus eines Dienstes ermöglichen. Dabei überschneiden sich die Themengebiete von SLA und PLA. Auch in SLAs werden bereits Sicherheitsparameter und -garantien verhandelt: Ein häufig anzutreffendes Beispiel hierfür ist etwa die Verfügbarkeit eines Dienstes. Der Hauptunterschied zu einem PLA besteht darin, dass ein PLA auch Sicherheitsgarantien abgeben soll, die keinen direkten Einfluss auf die Schnittstelle zwischen

32

Bundesamt für Sicherheit in der Informationstechnik

Grundlagen von Protection Level Agreements 4

Dienstleister und Mandanten haben, so z. B. die Garantie der Vertraulichkeit von Daten in Auftragsverarbeitungsszenarien. In der Forschung werden SLAs oft mit dem Begriff QoS (Quality of Service) als Ausdruck für das zugrunde liegende Qualitätsziel verbunden, analog erfolgt dies bei PLAs und QoP (Quality of Protection) [Kara 06]. Die wissenschaftliche Forschung fokussiert sich auf Fragen der Messbarkeit von Sicherheitsqualitäten [Veren 09] und geht wenig auf konkrete Fragen der vertraglichen Ausgestaltung eines PLAs ein. Diese Studie soll keine neuen experimentellen Metriken (wie z. B. die Beurteilung der Angreifbarkeit von Software anhand von Parametern wie aufgetretenen Störungen, Verschachtelungstiefe (als Komplexitätsmaßstab), Entwicklungsmodell oder historisch gefundenen Schwachstellen) entwickeln, wie dies in der wissenschaftlichen Diskussion um PLAs häufig versucht wird, sondern sie soll bestehende Metriken und Anforderungen dokumentieren und in eine Form bringen, die eine standardisierte Vorgehensweise erlaubt, und damit praktische Hilfestellung für die Umsetzung von Sicherheit in eigenen Dienstleistungsbeziehungen leisten. Im Rahmen einer konsistenten Betrachtung der Problemstellung und im Versuch, die wissenschaftliche Arbeit auf die betriebliche Praxis zu übertragen, erscheint es erforderlich, mit einer Definition von PLAs zu arbeiten, die der Definition des SLAs aus Kapitel 3 näher kommt.

4.2.1 Quality of Protection Der Begriff „Quality of Protection“ (QoP) bezeichnet ein Maß der Güte von Sicherheitsvorkehrungen und stellt den Versuch dar, die Qualität von Sicherheitsvorkehrungen quantitativ zu beschreiben. Im Gegensatz zur „Quality of Service“ (QoS) stammt der Begriff aus einem noch jungen Forschungsfeld, zu dem erst seit ca. 2005 Veröffentlichungen in einer nennenswerten Anzahl existieren. Eine akzeptierte Metrik existiert noch nicht; grundlegende Konzepte zur Messung von Sicherheitsparametern werden noch ausgelotet. In der Anwendungspraxis umfasst der Begriff (soweit er überhaupt verwendet wird) neben der Güte der Sicherheitsvorkehrungen vor allem die Beschreibung der Sicherheitsvorkehrungen an sich (so ist z. B. der Parameter QoP im WS-Security-Standard [OASIS 2004] ein Feld zur Auswahl eines kryptographischen Algorithmus). Abweichend von der eng definierten wissenschaftlichen Definition als Maß der Güte der Sicherheitsvorkehrungen soll als Bestandteil von Protection Level Agreements hier nicht nur die Güte (QoP), sondern vor allem auch die Definition der Sicherheitsvorkehrungen kommuniziert werden.

4.2.2 Protection Level Agreement Ein Protection Level Agreement (PLA) ist eine Vereinbarung, die die Regelungen zur Sicherstellung eines definierten Schutzniveaus im Sinne des IT-Sicherheitsmanagements im Rahmen einer Dienstleisterbeziehung beinhaltet. Bundesamt für Sicherheit in der Informationstechnik

33

4 Grundlagen von Protection Level Agreements

Das Protection Level Agreement definiert im Kontext dieser Studie also nicht nur eine variable Dienstgüte (QoP), sondern ein definiertes Schutzniveau (Protection Level). Trotz der auf den ersten Blick klaren Unterscheidung von „Service Level“ und „Protection Level“ überschneiden sich die Begriffe – vor allem im Bereich der Service-orientierten Architekturen – und damit auch die Inhalte von SLAs und PLAs. Beispiel: Verfügbarkeit ist als Qualitätsziel ein grundsätzlich definierten SLA-Parameter, gleichzeitig aber eines der drei Sicherheitsgrundziele (Verfügbarkeit, Integrität und Vertraulichkeit). Sowohl Überschneidungen als auch eine (willkürliche) Abgrenzung der verschiedenen Sicherheitsgarantien zwischen SLA und PLA sind problematisch, da sowohl SLA als auch PLA für sich alleine stehen können müssen. Nicht nur im Umfeld der Bundesverwaltung werden große Teile des Services von einem Dienstleister des Typs „interner Service-Provider“ erbracht, also einer internen Abteilung. Oft bestehen bei solchen Verhältnissen keine expliziten SLAs für die erbrachten Dienste. Nachträglich sind SLAs für bestehende Dienste oft nur schwer festzulegen. Dies gilt auch im Unternehmensbereich für ausgegliederte interne IT-Dienstleister. In solchen Szenarien kann das PLA daher für Regelungen des umzusetzenden Schutzniveaus eingesetzt werden, ohne dass die Problematik einer SLA-Vereinbarung insgesamt gelöst werden muss. Als Anforderung bedeutet dies, dass ein PLA einerseits Bestandteil eines Service Level Agreements sein können muss, andererseits jedoch als auch als eigenständiges Dokument ein Schutzniveau und erforderliche Maßnahmen zu seiner Erreichung beschreiben können muss. Die explizite Vereinbarungen zur Sicherheit einer erbrachten Leistung hat den zusätzlichen Vorteil, dass dieser wichtige Aspekt nicht stillschweigend im Vertrauen auf die jeweils andere Seite vernachlässigt wird. So ist es in der Praxis nicht selten, dass der Kunde vom externen Dienstleister die Umsetzung eines angemessenen Schutzniveaus implizit erwartet, während umgekehrt der Dienstleister davon ausgeht, nur die vom Kunden explizit formulierten Anforderungen umsetzen zu müssen. Die so entstehende „Regelungslücke“ tritt oftmals erst dann zu Tage, wenn bei einem tatsächlich eingetretenen Sicherheitsvorfall über die Verantwortung gestritten wird.

4.3

Ziele von Protection Level Agreements

Im Rahmen der gewählten Definition wird ersichtlich, dass die Ziele eines Protection Level Agreements sich mit den Zielen eines Service Level Agreements überschneiden. Im folgenden sollen die bereits dargestellten Ziele eines SLA (siehe Kapitel 2.1) für PLA wie folgt ergänzt werden:

4.3.1 Ziele im Interesse von Kunde und Dienstleister: Aus dem gemeinsamen Interesse von Kunde und Dienstleister lassen sich die folgenden Ziele definieren:

34

Bundesamt für Sicherheit in der Informationstechnik

Grundlagen von Protection Level Agreements 4

1. Erzielung von Leistungstransparenz: Durch die Festlegung messbarer Sicherheitsqualitäten und die Vereinbarung standardisierter Sicherheitsprozesse wird das beiderseitige Verständnis über die zu erbringende bzw. zu erwartende Leistung in Bezug auf die Sicherheit verbessert. 2. Anpassung der Dienstleistungen an die Anforderungen des Kunden: Der Schutzbedarf für einen bestimmten Service kann nur durch den Kunden definiert werden. Die Dienstleistung des Anbieters muss geeignet sein, dem Bedarf des Kunden an die Sicherheit der Dienstleistung gerecht zu werden. 3. Erzielung von Konsistenz hinsichtlich der erbrachten Dienstleistungsqualität: Die Schaffung eines messbaren Sicherheitsniveaus und die Standardisierung von Sicherheitsprozessen und Maßnahmen verbessern die Konsistenz der gemeinsamen Wahrnehmung der Leistung des Dienstleisters hinsichtlich des erreichten Schutzniveaus. Ebenso liefert sie den notwendigen Input für Prozesse der Risikoanalyse. 4. Regelung von Verantwortlichkeiten zwischen Kunde und Dienstleister: Prozesse im Incident Management erfordern eine zeitnahe Reaktion und reibungslose Zusammenarbeit bei beiden Vertragspartnern. Klare Verantwortlichkeiten gewährleisten diese Zusammenarbeit.

4.3.2 Ziele im Interesse des Dienstleisters: Die folgenden Ziele ergeben sich zusätzlich aus dem Interesse des Dienstleisters: 1. Fixierung von Kundenerwartungen: Durch die Einbeziehung von Sicherheitsparametern in die PLAs werden diesbezügliche Ansprüche des Kunden fixiert und dokumentiert. 2. Schaffung von Planungssicherheit und Investitionsschutz: Sicherheitsmaßnahmen können einen entscheidenden Einfluss auf die Kosten eines Services haben. Eine rechtzeitige Fixierung der Anforderungen des Kunden gibt diesbezüglich Planungssicherheit für den Dienstleister.

4.3.3 Ziele im Interesse des Kunden: Schließlich ergeben sich weitere Ziele aus dem Interesse des Kunden heraus: 1. Reduktion der IT-Risiken: Durch ein PLA werden IT-Risiken auch in OutsourcingSzenarien beherrschbar. Etablierte IT-Risikomanagementprozesse beginnen, auch in Dienstleisterszenarien zu funktionieren. 2. Erzielung von Kostentransparenz: Durch ein PLA werden die Anforderungen an das Sicherheitsmanagement explizit, und, wenn eine Kosten- und Leistungsrechung stattfindet, auch die daraus resultierenden Kosten transparent. 3. Reduktion der IT-Kosten: Durch die Transparenz der Kosten von Sicherheitsmaßnahmen kann ein dem Schutzbedarf eines Services angemessenes Sicherheitsniveau erreicht werden. Dies birgt gleichzeitig das Potential zum Einsparen von nicht benötigten Maßnahmen.

Bundesamt für Sicherheit in der Informationstechnik

35

4 Grundlagen von Protection Level Agreements

4.4

Voraussetzungen und Erfolgsfaktoren

Damit PLAs in der Praxis erfolgreich umsetzbar sein können, müssen verschiedene Voraussetzungen erfüllt sein. Dabei soll im Weiteren zwischen „harten“ Voraussetzungen und „weichen“ Erfolgsfaktoren unterschieden werden.

4.4.1 Voraussetzungen Notwendige Bedingungen Sicherheitsgarantien, die in einem PLA verhandelbar sein sollen, müssen eine Bedingung zwingend erfüllen: Sie müssen messbar sein. Da in einem PLA Anforderungen zwischen verschiedenen Parteien verhandelt werden, muss diese Voraussetzung noch ergänzt werden: Sie müssen objektiv messbar sein. Der Begriff der objektiven Messbarkeit bedeutet zunächst einmal, dass Messergebnisse von beiden Vertragsparteien akzeptiert werden müssen. Implizit bedeutet dies: - Die Bewertung des Messergebnisses darf nicht von äußeren Faktoren abhängen, die außerhalb

des Einflussbereichs der beiden Vertragsparteien liegen. - Die Bewertung des Messergebnisses muss allgemein nachvollziehbar sein, sobald mehr als zwei

Parteien involviert sind – in einem SOA-Kontext beispielsweise bei erst zur Laufzeit zusammengesetzten Services („late binding“). Diese beiden Bedingungen machen modellbasierte Metriken (außerhalb des Zwei-Parteien-Falles) schwierig bis unmöglich, da modellbasierte Metriken interpretationsbedürftige Parameter besitzen, die auf den konkreten Service nicht unbedingt zutreffen müssen. In der Praxis schließt dies vor allem risikobasierte Metriken aus – sie basieren entweder auf Modellen, die Annahmen über den Angreifer und die Ausnutzbarkeit von Schwachstellen treffen, oder auf Messungen, die externe Parameter (tatsächliche Angriffe, veröffentlichte Schwachstellen) verwerten. Messbarkeit PLAs sollen vor allem Garantien über Vorgänge hinter der Schnittstelle zum Kunden definieren, die für einen Kunden nicht oder nicht ohne weiteres einsehbar sind; beispielsweise die Verschlüsselung der Backup-Daten oder die physische Sicherheit der eingesetzten Server. Die Messbarkeit existiert daher in zwei Varianten: 1. Durch den Kunden selbst oder eine dritte Partei messbar. Dies sind klassische Parameter, die auch in SLA definiert werden können, wie z. B. die Verfügbarkeit, maximale Ausfallzeiten oder die Nutzung von bestimmten Verschlüsselungsstandards in der Kommunikation zum Kunden. Diese Parameter werden auch als externe Parameter bezeichnet (extern aus Dienstleistersicht). Sind die Parameter vom Nutzer messbar, bedeutet dies ebenfalls eine Messbarkeit durch vom Kunden alleine oder gemeinsam mit dem Dienstleister beauftragte unabhängige Dritte. Bei der Messung durch eine unabhängige dritte Partei wird von dieser eine Audit-Funktion wahrgenommen. 36

Bundesamt für Sicherheit in der Informationstechnik

Grundlagen von Protection Level Agreements 4

2. Nur intern durch den Dienstleister messbar. Einige Parameter sind für das erreichte Sicherheitsniveau einer Dienstleistung wesentlich, aber aus der Perspektive des Kunden überhaupt nicht sichtbar. Beispiele dafür wären bestimmte Konfigurationseigenschaften von Multimandantensystemen eines Dienstleisters oder die Einhaltung von bestimmten Passwortkomplexitätsregeln durch die Administratoren des Dienstleisters – solche Eigenschaften können oft nicht geprüft werden, ohne die Vertraulichkeit anderen Mandanten gegenüber zu verletzten. Manche Eigenschaften sind aber auch schlicht zu komplex, so das eine direkte Messung durch den Kunden zu aufwändig wird (z. B. die Forderung nach der Einhaltung von ISO 27001 auf Basis von IT-Grundschutz). Sollen diese Eigenschaften kontrolliert werden, wird ein gemeinsam anerkannter Garant benötigt, der sie bestätigen kann. Das Beispiel einer ISO 27001 Zertifizierung auf Basis von ITGrundschutz bietet sich hier an, das Konzept des Zertifikats bzw. der zertifizierten Eigenschaft kann aber auch sehr viel kleinteiliger genutzt werden, z. B. auf der Ebene einzelner Systeme oder Komponenten. Wichtig für ein solches Zertifikat ist vor allem die Definition einer Vertrauenskette bzw. möglicher Wurzeln einer solchen Kette. Aus Kundensicht ergeben sich drei Güteklassen der Bestätigung. Abbildung 4 zeigt diese Klassen in aufsteigender Reihenfolge der Vertrauenswürdigkeit für den Kunden.

Abbildung 4: Messbarkeit und Vertrauen in Sicherheitsgarantien

1. Durch den Dienstleister bestätigt („zugesichert“) Dies ist für alle Sicherheitsanforderungen und durch die Vereinbarungen eines PLAs implizit gegeben.

Bundesamt für Sicherheit in der Informationstechnik

37

4 Grundlagen von Protection Level Agreements

2. Bestätigung durch unabhängige Dritte („zertifiziert“) Die Bestätigung durch unabhängige Dritte kann im Auftrag des Kunden für durch ihn selbst kontrollierbare Eigenschaften übernommen werden – in diesem Fall nimmt die dritte Partei eine Audit-Funktion wahr. Diese Audit-Funktion kann auch durch eine gemeinsam von Kunde und Dienstleister gewählte Kontrollinstanz durchgeführt werden, deren Ergebnisse von beiden Parteien als faktische Beurteilung akzeptiert werden. Dies ist schon deshalb wünschenswert, damit Unstimmigkeiten über das Ergebnis von Überprüfungen vermieden werden können. Bei der Bestätigung nicht direkt durch den Kunden überprüfbarer Sicherheitsgarantien benötigt die Kontrollinstanz eine Vertrauenswürdigkeit, die sich nur aus ihrem Überprüfungsstandard ergeben kann. Praktisch werden hier nur etablierte Standards und Zertifikate bestehen können, für die eine akzeptierte Prüfnorm existiert. 3. Direkte Messung durch den Kunden („überprüft“) Dies sind klassische SLA-Parameter wie z. B. die Verfügbarkeit, maximale Ausfallzeiten oder die Nutzung von bestimmten Verschlüsselungsstandards in der Kommunikation zum Kunden. Sind die Parameter vom Nutzer messbar, bedeutet dies ebenfalls eine Messbarkeit durch vom Kunden alleine oder gemeinsam mit dem Dienstleister beauftragte unabhängige Dritte. Vorteilhaft bei der Messung durch den Kunden selbst ist meist die zeitnahe Erfassung und damit die Möglichkeit einer unmittelbaren Reaktion. Ein wichtigeres Kriterium ist aber oft die Frage nach Aufwand und Risiko bei der Einbindung von weiteren externen Parteien in die jeweilige Systemarchitektur. Wird ein Dienst z. B. im Internet für die Öffentlichkeit angeboten, bietet sich eine externe Überprüfung von beispielsweise der Schnittstellensicherheit und der Verfügbarkeit an; ein Audit kann von jedem Netzwerkzugang aus durchgeführt werden, die Aussagen über die Verfügbarkeit gewinnen an Relevanz, wenn von verschiedenen Punkten aus gemessen wird. Ist dieselbe Schnittstelle aber nur für bestimmte Systeme im Intranet einer Organisation verfügbar, muss für die Kontrollinstanz zunächst ein Zugang geschaffen werden, der nicht selbst zu einem Sicherheitsrisiko führt. Die Garanten der Zusicherung einer Sicherheitseigenschaft sollten dabei explizit mit jeder Eigenschaft spezifiziert werden, um Missverständnisse auszuschließen.

4.4.2 Erfolgsfaktoren Für den praktischen Erfolg einer Spezifikation von PLAs sind aber auch „weichere“ Faktoren notwendig. Grundsätzlich gelten die individuellen Erfolgsfaktoren aus dem SLM-Prozess aus Kapitel 3.3 hier äquivalent. Neben diesen Faktoren sollen aber auch die Erfolgsfaktoren für eine (in den späteren Kapiteln zu definierende) Umsetzung betrachtet werden.

38

Bundesamt für Sicherheit in der Informationstechnik

Grundlagen von Protection Level Agreements 4

Standardisierung Der wichtigste Erfolgsfaktor ist die Standardisierung. Bisher sind noch keine Standards etabliert und bestehende Frameworks beschränken sich auf die Definition des Rahmens. Für Inhalte von PLAs existiert also noch keine akzeptierte Grundlage. Eine Standardisierung bietet die folgenden Chancen und Vorteile, die nicht nur den Erfolg des Standards an sich betreffen, sondern vor allem die Lösung der im Kapitel 4.1 (Ausgangslage) beschriebenen grundlegenden Fragestellungen. - Die Standardisierung bestimmter technischer Lösungen für eine Problematik erlaubt es,

gemeinsame Lösungen für Multimandantensysteme zu erzeugen, die von allen Mandanten akzeptiert werden. Oft zeigen sich Probleme bei der Verhandlung mit Dienstleistern vor allem in den Bereichen, in denen sich die individuellen Sicherheitskonzepte in den Details widersprechen. Beispiel: Kryptographische Methoden. Alle Mandanten möchten zwar eine sichere Authentifizierung, schreiben aber in ihrem Kryptokonzept dafür unterschiedliche Algorithmen vor. Möchte der Anbieter z. B. ein heute sicheres Hash-Verfahren nutzen, wird er mindestens SHA-384 oder SHA-512 nutzen. In älteren Kryptokonzepten sind diese Verfahren evtl. noch nicht aufgeführt, da von einer längeren Nutzung von SHA-1 oder MD5 ausgegangen wurde. Eine passende Lösung erfordert so jedes Mal umfangreiche Anpassungen oder Verhandlungen. - Aufgrund derselben Argumentation lassen sich durch eine Standardisierung einheitliche

Sicherheits-Vorgaben für Subauftragnehmer erstellen. Dies erlaubt es den Anbietern, definierte Sicherheitsprofile anzubieten, die über die gesamte Kette von Subauftragnehmern eingehalten werden. - Akzeptierte Prüfnormen lassen eine unabhängige Zertifizierung zu: Bei der

Vereinbarung von möglichen Sicherheitsgarantien (siehe auch Abbildung 3 auf S.19) sind für alle Vertragsparteien in vielen Fällen nur die durch Dritte zertifizierten Parameter akzeptabel. Ohne einen Standard, der zu akzeptierten Prüfnormen und -angeboten führt, fällt ein nennenswerter Anteil der Sicherheitsgarantien entweder in die Kategorie „nur vom Dienstleister messbar“ oder „Kunde prüft selbst“. - Eine Standardisierung bringt ein erhebliches Kosteneinsparungspotential auf

Anbieterseite. - Eine weitere Chance von standardisierten PLAs kann es sein, dass sich auch Prüfungen und

Zertifizierungen von Submengen eines Standards oder einzelner Sicherheitsgarantien etablieren können, z. B. die Zertifizierung der Umsetzung von einzelnen ITGrundschutzmaßnahmen oder -bausteinen. - Die Standardisierung erlaubt es, Profile und Klassifikationen für häufige

Anwendungsfälle zu erstellen und Anwendungen danach zu kategorisieren. Sollen Dienstleister die Sicherheitsrichtlinien mehrerer Auftraggeber einhalten, führt dies unweigerlich zu Kollisionen, wenn die Prioritäten der Sicherheitsziele nicht übereinstimmen. Ein häufiger Konflikt betrifft die Abwägung der Vertraulichkeit und Integrität gegen die Verfügbarkeit. Ein Beispiel: bei sehr hohen Vertraulichkeits- und Integritätsanforderungen mag es gerechtfertigt erscheinen, den Betrieb sofort einzustellen, wenn keine Verbindung zum

Bundesamt für Sicherheit in der Informationstechnik

39

4 Grundlagen von Protection Level Agreements

Protokollierungsserver mehr besteht, für eine Anwendung mit hohen Verfügbarkeitsanforderungen und geringeren Vertraulichkeitsanforderungen ist dies wahrscheinlich nicht der Fall. Komplexität Neben der Standardisierung zeigt die Erfahrung2, dass eine einfache Anwendbarkeit erfolgsbestimmend ist. Eine einfache Anwendbarkeit geht bei einem solchen Standard einher mit einer möglichst geringen Komplexität. - Zumindest die Wahrnehmung von einfacher Anwendbarkeit und geringer Komplexität

hängen meist voneinander ab. Die Wahrnehmung bestimmt mit über den Erfolg. - Eine geringe Komplexität führt aber auch unabhängig von dieser subjektiven Beurteilung zu

einem geringeren Risiko. Systeme mit hoher Komplexität bedeuten immer auch eine erhöhte Fehleranfälligkeit und stellen damit in sich ein eigenes Sicherheitsrisiko dar.

4.5

Inhalte von Protection Level Agreements

PLAs enthalten Vereinbarungen, die sowohl die Schnittstellen des organisatorischen Ablaufs des Sicherheitsmanagements auf beiden Vertragsseiten als auch die Sicherheitsgarantien des vereinbarten Dienstes regeln.

4.5.1 Entkopplung von Sicherheitsanforderungen Sicherheitsanforderungen sind an den Schutzbedarf gekoppelt; der Schutzbedarf hängt wesentlich von den zu verarbeitenden Daten ab. In vielen Situationen können die Sicherheitsanforderungen erheblich eingeschränkt werden, wenn Daten entweder nicht oder nur verschlüsselt gespeichert werden. In Fällen, in denen die Sicherheitsanforderungen sich nicht direkt auf die Daten beziehen, beziehen sie sich zumindest auf die Systeme, die diese Daten verarbeiten. Schutzmaßnahmen für die Systeme können vom Umfang her eingeschränkt werden, indem Systeme für Services mit hohem und niedrigerem Schutzbedarf getrennt werden. Beides bewirkt eine Entkopplung der Sicherheitsrisiken vom schutzbedürftigen Service. Die sich hieraus ergebene Reduktion von Schutzmaßnahmen beeinträchtigt die Sicherheit nicht. Im Gegenteil – sie gewährleistet die Sicherheit bei geringeren Kosten. Wo immer möglich, sollte auf eine solche Entkopplung der Sicherheitsrisiken gesetzt werden. Statt ein starres Schema vorzugeben, kann die Entkopplung in den PLA „sanft“ mit aufgenommen werden, in dem die Bedingungen für Maßnahmen genau definiert werden oder indem Ausnahmen formuliert werden, z. B.: „Die Einschränkungen für Systeme mit vertraulichen Daten gelten nur für Systeme, auf denen die Daten unverschlüsselt vorhanden sind oder auf denen Schlüssel vorgehalten werden.“ 2 Eine Formalisierung dieses Gedankens ist auch als „Technology Acceptance Model“ [TAM] bekannt. TAM postuliert, dass der Erfolg einer neuen Technologie von zwei Faktoren abhängig ist: „Perceived Usefulness“ (PU) und „Perceived Ease-of-Use“ (PEOU) 40

Bundesamt für Sicherheit in der Informationstechnik

Grundlagen von Protection Level Agreements 4

Mit diesem Ansatz ist es dem Dienstleister möglich, Komplexität zu reduzieren durch eine Entkopplung an den Stellen mit dem größten Sparpotenzial.

4.5.2 Sicherheitsgarantien Wichtigster Bestandteil eines PLAs sind Vereinbarungen über das zu erbringende Schutzniveau. Hierbei sichert der Dienstleister die Erreichung bestimmter Leistungsmerkmale, Sicherheitsgarantien genannt, zu. Dies können sowohl qualitative Aussagen wie das Vorhandensein bestimmter Zertifizierungen, als auch quantitative Aussagen sein, wie z. B. messbare Prozesskennzahlen oder technische Parameter, die das erreichte Schutzniveau in der ITInfrastruktur des Dienstleisters abbilden. Bereiche Die vereinbarten Sicherheitsgarantien betreffen grundsätzlich die beiden Bereiche: - Organisatorisch: Aussagen über die Qualität des Sicherheitsmanagementsystems und seiner

Prozesse („Prozessmerkmale“) - Technisch: Aussagen über die Qualität der umgesetzten technischen Sicherheitsmaßnahmen

(„technische Merkmale“) Metriken Bezüglich der Art der Sicherheitsgarantien können ebenfalls zwei Fälle unterschieden werden: - Qualitativ: Es wird die Anwesenheit oder Abwesenheit eines bestimmten Merkmals

zugesichert, z. B. das Vorhandensein einer Zertifizierung, der Einsatz eines Virenscanners oder die Nichtverwendung bestimmter unsicherer Technologien. - Quantitative Metrik: Für die Bestimmung des Leistungsmerkmals wird eine messbare

Kenngröße herangezogen, d. h. es wird ein Mindest- und/oder Höchstwert vorgegeben. Im Kontext von PLAs ist der Gegenstand der Messung entweder ein für die Sicherheit relevanter Geschäftsprozess oder ein technisches System. Bestandteil eines PLAs sollten also Vereinbarungen sein, die für bestimmte Kenngrößen mit Aussagekraft über das Erreichen des festgelegten Schutzniveaus Mindest- oder Höchstwerte vorschreiben. Die vereinbarten Kenngrößen für die Sicherheitsgarantien haben im optimalen Fall folgende Eigenschaften: - Klarheit: Die Kenngröße sollte leicht zu interpretieren sein, es sollte kein Zweifel an der

konkreten Bedeutung einer Kenngröße und ihrer Interpretation bestehen. - Objektivität: Die Messung der Kenngröße sollte unabhängig von Einflüssen und Erwartungen

durch den Messenden sein, damit das Ergebnis der Messung auch für Dritte eine sinnvolle Aussage beinhaltet. - Wiederholbarkeit: Das Ergebnis einer Messung sollte bei gleicher Durchführung identisch sein.

Je größer der Fehler der Messung bei wiederholter Durchführung, desto geringer die Aussagekraft des Messwertes.

Bundesamt für Sicherheit in der Informationstechnik

41

4 Grundlagen von Protection Level Agreements

- Simplizität: Je komplexer die Erhebung einer Kenngröße, desto größer der mögliche Fehler und

die Kosten der Erhebung. Einfach zu messende Größen sind zu bevorzugen. - Ausdruckskraft: Eine Kenngröße sollte mit möglichst einfachen Mitteln die wichtigen

Eigenschaften des Messgegenstandes erfassen, also bei PLAs eine (aus Kundensicht) möglichst gute Aussage über das erreichte Schutzniveau erlauben. Zertifizierende Stelle Die Überprüfung der Einhaltung eines PLAs durch Prüfung der Kenngrößen ist nicht immer unmittelbar möglich, auch wenn dies bei der Ausgestaltung der Dienstleisterbeziehung entsprechend berücksichtigt wurde, weil ein direkter Zugang zu den für die Kenngrößenermittlung benötigten Daten nicht möglich oder nicht gewünscht ist. Ein möglicher Lösungsweg ist hier, interne Kenngrößen des Dienstleisters zu externalisieren, indem durch unabhängig durchgeführte Audits entsprechendes Vertrauen in die korrekte Erhebung der zugrunde liegenden Daten geschaffen wird (siehe Abschnitt 4.4.1). Daher sollte für jede Sicherheitsgarantie im PLA eine prüfende Stelle bzw. ein Garant (siehe Kapitel 4.4.1) definiert werden. Der Garant wird für jede Garantie explizit aufgeführt und ist entweder - der Anbieter („zugesichert“), - der Kunde („überprüft“), - oder eine dritte Partei („zertifiziert“).

4.5.3 Prozesskenngrößen Prozesskenngrößen sind oft qualitativer Natur, bestehen also in der Einhaltung bestimmter Maßnahmen. Die Quantifizierung von Prozesskenngrößen kann auf zwei Ebenen geschehen: Einmal durch quantifizierbare Merkmale wie die Einhaltung bestimmter Zeiträume für Prozessabläufe. Zum anderen können qualitative Merkmale wie z. B. der Reifegrad von Prozessen nach SSE-CMM gemessen werden. Qualitative Merkmale sind nicht einfach oder direkt messbar und oft subjektiv beeinflusst, d. h. nicht ohne externe Zertifizierung messbar. Beispiele für qualitative Kenngrößen sind: - Standards für die Gewährleistung der Sicherheit: Es existieren Standards, die ein

angemessenes IT-Sicherheitsmanagement beschreiben. Hierzu gehören insbesondere der die BSI-Standards zum IT-Grundschutz sowie die ISO-Standards 27001 und 27002 [ISO 27002]. Ein PLA kann die Einhaltung eines solchen Standards vorschreiben. Der Nachweis des Einhaltens eines Standards erfolgt dabei üblicherweise über ein Audit durch einen unabhängigen Dritten, der ein entsprechendes Zertifikat ausstellt. Eine regelmäßige Rezertifizierung ist hierbei üblich bzw. wird von den Standards selbst eingefordert. - Einhaltung bestimmter Maßnahmen (Controls): Ein PLA kann die Einhaltung bestimmter

Teile eines übergeordneten Standards beinhalten, so z. B. die Umsetzung bestimmter Maßnahmen oder Bausteine der IT-Grundschutz-Kataloge. Hier überschneiden sich Prozess- und technische Kenngrößen.

42

Bundesamt für Sicherheit in der Informationstechnik

Grundlagen von Protection Level Agreements 4

Beispiele für quantitative Prozesskenngrößen sind: - Reaktionszeit im Incident Management: Die Zeit, die zwischen dem Einstellen eines Incidents

durch den Kunden bis zur Reaktion oder bis zur erfolgreichen Bearbeitung durch den Dienstleister vergeht. - Zeit bis zum Einspielen sicherheitskritischer Patches: Die maximale Zeit, die nach dem

Erscheinen von sicherheitskritischen Patches bis zum Einspielen auf den Systemen vergehen darf. Dies ist ein Beispiel für einen üblicherweise komplexen Parameter, der von anderen Faktoren wie Kritikalität (für die es oft verschiedene Einstufungen gibt), Testzeitraum und Testergebnis sowie vom Schutzbedarf des Systems abhängt.

4.5.4 Technische Parameter Technische Parameter können eine Vielzahl von Formen annehmen. Die konkrete Ausgestaltung ist oftmals eine Umsetzung der Maßnahmen im Rahmen des IT-Sicherheitsmanagementprozesses. Im Folgenden werden Beispiele für technische Parameter genannt, die in einem PLA vereinbart werden können. Diese Beispiele sind – auch wenn dies auf den ersten Blick anders erscheinen mag – ausschließlich qualitativer Natur. - Güte der Sicherheit der Verbindung oder der persistenten Datenhaltung: Hierunter sind

konkrete Schutzziele bei der Übertragung und Speicherung von Daten zu verstehen, also z. B. einzuhaltende Verschlüsselungsverfahren von Leitungen und Datenspeichersystemen, Redundanz durch mehrfache Netzanbindung, RAID-Verfahren, Backups. - Angaben zur Verschlüsselungstiefe: Es existiert eine Vielzahl kryptographischer Verfahren,

die als Bausteine in Sicherheitskonzepten verwendet werden. Unter Berücksichtigung des Standes der Technik und der zu erwartenden Zeit, für die diese Verfahren in der Zukunft den Anforderungen genügen müssen, ist eine entsprechende Auswahl von Algorithmen und Parametern zu treffen. - Angaben zur Signaturerstellung: Analog zur Verschlüsselung muss auch bei der Erstellung

von Signaturen auf die Auswahl geeigneter Algorithmen und deren Parametern geachtet werden. - Sicherheitsgütesiegel von Firewalls und Application Level Gateways: Bestimmte zentrale

Komponenten in einem IT-System sind für das Erreichen des angestrebten Schutzniveaus kritisch. Dazu gehören z. B. Firewalls. Es ist oftmals sinnvoll, für solche Komponenten eine Zertifizierung nach einem anerkannten und für den Einsatzzweck angemessenen Standard zu fordern (beispielsweise Common Criteria mit passendem EAL und Schutzprofil) - Wiederkehrende Schlüsselgenerierung und Schlüsselverteilung: In vielen Szenarien sind die

kryptographischen Schlüssel kritische Bestandteile des Sicherheitskonzepts. Mithin hängt vom ordnungsgemäßen Umgang mit den Schlüsseln der Erfolg beim Erreichen der Schutzziele ab. Ein PLA kann deswegen Parameter des Umgangs mit Schlüsseln vorschreiben, so die physische Sicherung der Schlüsselgenerierung, die maximale Lebensdauer von Schlüsseln oder die Verwendung angemessener Transportschlüssel. Hierbei existiert ein fließender Übergang zu organisatorischen Regelungen, z. B. zu Maßnahmen bei Schlüsselverlust. Eine umfassende Darstellung in einem PLA zu vereinbarenden Prozesskenngrößen und technischen Parameter findet sich in dem im folgenden Kapitel vorgestellten Template. Bundesamt für Sicherheit in der Informationstechnik

43

5 PLA-Template

5

PLA-Template

5.1

Vorüberlegungen

Die hier beschriebene Vorlage soll den Weg einer praktikablen Vereinbarung von Sicherheitsgarantien zwischen zwei Partnern aufzeigen. Dabei existiert eine hohe Anzahl von potenziellen qualitativen Maßnahmen, die in einem PLA vereinbart werden können. Die vertragliche Betrachtung aller dieser Maßnahmen ist bei einer ausgelagerten Bearbeitung oft weder gewollt (wegen der hohen Komplexität) noch nötig, da viele der technischen Maßnahmen nur Mittel zur Implementierung des vereinbarten Schutzniveaus sind. Die Definition des Schutzniveaus ist dabei die wesentliche Herausforderung. Das Schutzniveau wird jeweils für Schutzziele definiert. Für die Grundwerte der Informationssicherheit bedeutet dies: - Verfügbarkeit: Für die Verfügbarkeit sind seit langem gut verstandene und in der Praxis

etablierte Maßstäbe bekannt. Zuerst wird für den Zustand „verfügbar“ eine Messung definiert, die idealerweise der Wortbedeutung für den Service-Nutzer entspricht, d. h. der Nutzbarkeit des Dienstes durch den Service-Nutzer. Zu den relevanten Kenngrößen gehören: - Prozentuale Verfügbarkeit über einen Zeitraum - Maximale Ausfallzeit pro Vorfall und über einen Zeitraum - Maximale Antwortzeiten für definierte Anwendungsaufgaben - Maximale Anzahl von Abweichungen für Antwortzeiten in einem bestimmten Zeitraum

und weitere Varianten der Messung einer Anwendungsantwort. Für die Integrität und Vertraulichkeit sind dagegen keine äquivalenten Maßstäbe verfügbar. Eine direkte Analogie zu Ausfallzeiten bzw. zum Verlust der Verfügbarkeit wären konkrete Angaben über eine maximale Anzahl von Verstößen gegen die Vertraulichkeit bzw. Integrität innerhalb eines bestimmten Zeitraums. Es existieren auch Studien (z. B. [Guti2005]), die sich mit solchen Parametern auseinandersetzen. Doch übersetzt man diese Zahlen in konkrete Beispiele, wird deutlich, dass eine vertragliche Regelung dieser Art auf Schwierigkeiten stoßen würde: - Integrität, z. B. im Bankenumfeld: Bei maximal einer Überweisung in zehn Jahren darf eine

falsche Summe überwiesen werden. - Vertraulichkeit, z. B. im Serverbetrieb: Maximal einmal in zehn Jahren dürfen vertrauliche

Dokumente des Kunden versehentlich in die Öffentlichkeit geraten, dabei dürfen pro Vorfall insgesamt nur 0,5% der gesamt gespeicherten vertraulichen Dokumente öffentlich werden. Solche Vereinbarungen sind offensichtlich praxisfremd. Hier stellt sich die Frage, worin sich dieser Unterschied in der Behandlung der Sicherheitsziele begründet. Dabei soll erst einmal gleichgültig sein, dass allein die Erkennung dieser Ereignisse in der Praxis häufig schwierig ist – zumindest für den Kunden. Dies ist aber keine prinzipielle Limitierung. Bei Verletzungen der Vertraulichkeit und Integrität handelt sich im Gegensatz zur Verfügbarkeit um besonders seltene Ereignisse. Anders als bei der Verfügbarkeit, bei der ein gewisses Maß an

44

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

Vorkommnissen im Betrachtungszeitraum als unvermeidbar angenommen wird, geht der Auftraggeber im Regelfall davon aus, dass Verstöße gegen Vertraulichkeit und Integrität möglichst vollständig ausgeschlossen oder zumindest hinreichend unwahrscheinlich gemacht werden sollen. Dieses Phänomen des „seltenen Ereignisses“ lässt sich für die weitere Betrachtung wie folgt definieren: „Seltene Ereignisse“ bei der Vereinbarung von PLAs sind solche Ereignisse, bei denen mit einem statistischen Auftreten von weniger als einem Ereignis während des Betrachtungszeitraums (Vertragslaufzeit) gerechnet wird. Bei solchen seltenen Ereignissen ist eine praktische Messung während des Vertrages nicht aussagekräftig genug, um die Einhaltung zu überwachen. Entsprechend der Definition erwartet der Kunde, dass keines dieser seltenen Ereignisse im Betrachtungszeitraum eintritt. Der angewendete Maßstab ist daher üblicherweise die Senkung der Eintrittswahrscheinlichkeit solcher Ereignisse aufgrund theoretischer Überlegungen (Sicherungsmaßnahmen). Die IT-Grundschutz-Kataloge des BSI stellen anhand typischer Gefährdungen eine Sammlung solcher Maßnahmen für konkrete IT-Landschaften dar. In der Praxis bedeutet dies, dass eine Messung der tatsächlichen Performance der Sicherungsmaßnahmen zumindest durch den Kunden nicht möglich ist. Auf Seiten des ServiceProviders besteht eventuell die Möglichkeit, eine Messung über alle betreuten Mandanten zu führen, z. B. in der Art „ein Vorfall pro 100 Kunden“. Um dieses Problem zu umgehen, ist einer der häufigsten Ansätze, das Risiko zu messen (z. B. [Mora2009]). Dabei können sehr unterschiedliche Metriken genutzt werden, die vom Auftreten von Schwachstellen ([Abed2006], [Vach2009]) bis hin zu Betrachtungen über die Prozessreife [Mass2007] reichen. Trotz hoher Bemühungen, einen objektiven Maßstab zu finden, sind alle Risiko-basierten Maßstäbe offen für Interpretation. In der Bemühung, die Metrik selbst objektiv zu gestalten, verletzten solche Metriken oft noch eine grundlegende Bedingung: Sie sind nur mittelbar vom Dienstleister beeinflussbar (z. B. die Anzahl bekannter Schwachstellen). An Stelle von entweder nur subjektiv definierbaren Maßstäben oder objektiv quantifizierbaren, aber seltenen Metriken tritt deshalb die Erfüllung konkreter Sicherungsmaßnahmen, die das Eintrittsrisiko der Ereignisse senken. Eine Messung erfolgt rein qualitativ durch die Feststellung, ob diese Maßnahmen erfolgreich umgesetzt wurden. Die Schwierigkeit der Übernahme solcher qualitativen Metriken (Umsetzung von Maßnahme X) in eine Vereinbarung zwischen zwei Parteien (PLA) zeigt sich beim Vergleich mit den ITGrundschutz-Katalogen: 1. Die Menge der erforderlichen Maßnahmen ist typischerweise hoch. Die Aufnahme von Einzelmaßnahmen in der Größenordnung der IT-Grundschutz-Kataloge bietet für ein PLA kaum zu überwindende Probleme bei - der Abstimmung einer so komplexen Vertragsbeziehung und - den monetären Auswirkungen der Aufwände, die sich aus den Maßnahmen ergeben.

2. Die Menge und Art der Maßnahmen ist zeitlich variabel. Viele Maßnahmen zielen gegen bestimmte (wahrscheinliche) Angriffsszenarien, beispielsweise XSS und Code-Injektion bei Webanwendungen. Diese Angriffsszenarien und damit auch die Verteidigungsmaßnahmen

Bundesamt für Sicherheit in der Informationstechnik

45

5 PLA-Template

ändern sich mit der Zeit, so dass ein im Detail ausformuliertes PLA einen hohen Pflegeaufwand inkl. Abstimmung zwischen den beteiligten Parteien mit sich brächte, der in der Praxis nicht realistisch umsetzbar erscheint.

5.2

Lösungsansatz

Ausgehend von der Erkenntnis, dass einerseits eine vollständige Beschreibung der erforderlichen Sicherheitsmaßnahmen in einer Dienstleister-Dienstnutzer-Beziehung wegen der Komplexität und dem damit verbundenen Pflegeaufwand unpraktikabel ist, gleichzeitig aber die Vereinbarung bestimmter Sicherheitsparameter (z. B. für die Verfügbarkeit) auch explizit erfolgen soll, sieht das hier vorgestellte PLA-Template zwei Aspekte vor, die in der folgenden Grafik verdeutlicht werden:

Abbildung 5: Sicherheitsziele und Maßnahmen im PLA

In diesem Modell werden - einerseits die Sicherheitsziele für die vom Dienstleister erbrachten Services vollständig und

möglichst präzise im PLA ausformuliert, um eine definierte Grundlage für die Ermittlung eines angemessenen Schutzniveaus zu liefern. - andererseits ausgewählte Sicherheitsmaßnahmen zu sinnvollen Regelungsbereichen im PLA

explizit ausgestaltet. Dabei ist zu beachten, dass die explizit im PLA aufgeführten Maßnahmen keinen vollständigen Katalog für die Erreichung der Sicherheitsziele darstellen können und sollen. Der Dienstleister ist vielmehr verpflichtet, durch sein eigenes IT-Sicherheitsmanagement geeignete Maßnahmen zur

46

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

Erreichung der vereinbarten Sicherheitsziele auch für die nicht im PLA geregelten Bereiche zu definieren und umzusetzen. Durch diesen Ansatz bleibt die Vereinbarung, Überprüfung und Fortschreibung des PLAs für beide Seiten beherrschbar, ohne dass auf eine umfassende Absicherung der Services verzichtet wird. Vielmehr haben die Parteien bei der Ausgestaltung der explizit vereinbarten Maßnahmen die Möglichkeit, den Umfang und Detaillierungsgrad je nach Schutzbedarf der erbrachten Services individuell auszugestalten.

5.3

Szenarien

Als Grundlage für die Erstellung des Templates wurden zunächst verschiedene relevante Szenarien betrachtet. Erst einmal stellt sich die Frage nach einem sinnvollen Abgrenzungskriterium der einzelnen Szenarien. Eine Abgrenzung nach Inhalten erscheint hier wenig sinnvoll, da dies u. U. dazu führen würde, dass für eine konkrete Leistungsbeziehung mehrere verschiedene PLAs zu verhandeln, abzuschließen und zu pflegen wären, was unrealistisch und wenig praktikabel erscheint. Die Szenarien müssen daher für jeweils eine Leistungsbeziehung die relevanten Sicherheitskriterien vollständig abdecken. Die Abgrenzung der Szenarien muss entsprechend der Abgrenzung verschiedener denkbarer Vertragsbeziehungen aus der Konstellation der beteiligten Parteien in einer SOA hervorgehen, wie in der folgenden Abbildung 6 schematisch dargestellt ist:

Abbildung 6: Auftragsverhältnisse in serviceorientierten Architekturen

In der Beziehung von mehreren Service Providern untereinander (Szenario B) tritt dabei ein Service Provider gegenüber dem anderen als Service Consumer auf, so dass sich dieses Szenario komplett analog auf das Szenario A abbilden lässt. Die in Abbildung 6 aufgeführten Szenarien A, C und D decken dadurch den gesamten relevanten Bereich an Vertragsbeziehungen ab. Bundesamt für Sicherheit in der Informationstechnik

47

5 PLA-Template

Die Szenarien C und D stellen zusammen den Sonderfall dar, dass der Service Consumer dem Service Provider die Nutzung eines bestimmten anderen Service-Providers vorschreibt, wie im Beispiel eines externen Identity Providers (denkbar wären auch andere Szenarien, z. B. ein StorageDienstleister). Diese Vorschrift kann zu einer Risikokopplung in den Schutzzielen führen, d. h. der Service-Provider ist in seinen Garantien für das Szenario (A) abhängig von den Leistungen des ihm vom Kunden vorgegebenen Dienstleisters. Vertraglich ist dieser gemeinsame Provider gegenüber beiden Parteien ein normaler „Service Provider“, allerdings für unterschiedliche Dienste. Letztendlich lassen sich die hier abgebildeten Beziehungen C und D unter Berücksichtigung der vorgenannten Besonderheit daher jeweils auch als Vertragsbeziehungen nach dem PLA-Typ A modellieren. Am häufigsten dürfte diese Konstellation für einen Identity Provider (Authentifizierungsdienst) vorkommen. Ein Identity Provider ist ein eigenständiger Authentifizierungsdienst, der den Kunden bzw. dessen Mitarbeiter gegenüber mehreren Service-Providern authentifizieren kann. Organisationsintern würde man diese Funktionalität als Single-Sign-On bezeichnen. Der Identity Provider gibt dabei nur die vom Benutzer autorisierten Informationen an den eigentlichen ServiceProvider weiter. Ein Identity Provider ist gleichzeitig ein Beispiel für einen Dienst mit hoher Risikokopplung: Sowohl Verfügbarkeit als auch Vertraulichkeit und Integrität sind abhängig von den Sicherheitsgarantien des Identity Providers. Von der Vertragsbeziehung genauso gelagert wäre der Dienst des Service-Brokers, der ebenfalls die beidseitige Vertrauensstellung benötigt. Die Abhängigkeiten sind hier allerdings eher implizit gegeben – der Kunde gibt dem Dienstleister die Nutzung indirekt vor, in dem er einen bestimmten Broker nutzt. Wichtig bei einer solchen Vertragskonstellation ist die explizite Definition der Risikokopplung im PLA. Im Ergebnis gibt es dazu zwei Modelle: Expliziter Ausschluss der Risiken durch den gemeinsamen Dienstleister Hier werden die betroffenen Sicherheitsgarantien nur unter dem Vorbehalt der Funktionalität des gemeinsamen Dienstleisters abgegeben. Die Erhöhung des Risikos bzw. die Senkung der Gesamtverfügbarkeit muss durch den Service Consumer abgefangen werden. Dies entspricht einer klassischen Orchestrierung bzw. Nutzung mehrerer Dienste. Die Vertragsbeziehung C hat dabei nur noch sehr wenig Regelungsbedarf, die Vertragsbeziehung D ist durch ein PLA zwischen Service Consumer und dem gemeinsamen Dienstleister entsprechend abzudecken. Expliziter Einschluss der Risiken durch den gemeinsamen Dienstleister Dieser Weg ist aus Sicht des Service Consumers erstrebenswert, da er das Risikomanagement für ihn wesentlich vereinfacht. Für diesen Weg bedarf es eines expliziten PLAs für beide Vertragsbeziehungen C und D. Das hier entwickelte Template ist für alle genannten Szenarien geeignet. Die hier vorgestellten Besonderheiten der Szenarien C und D müssen dabei bei der inhaltlichen Ausgestaltung des Templates entsprechend berücksichtigt werden.

48

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

5.4

Gliederung

Wie die vergangenen Kapitel gezeigt haben, bestehen zwischen PLAs und SLAs zwangsläufig umfangreiche Überschneidungen. Ein PLA lässt sich geradlinig als Erweiterung eines SLAs um Sicherheitsbelange modellieren. In Situationen, in denen bisher kein SLA bestand oder kein SLA vorgesehen ist, müssen daher die Grundlagen für eine solche Vereinbarung erst noch geschaffen werden. Abbildung 7 zeigt die im Vergleich zur in Kapitel 3.4 vorgestellten Gliederung eines SLAs gleichbleibenden Punkte und soll der Verdeutlichung dienen, dass eine PLA-Vereinbarung ohne SLA nicht sinnvoll darstellbar ist. Dies liegt auch daran, dass der inhaltliche Hauptteil eines SLA, die Beschreibung der IT-Service-Qualitäten, fast vollständig vom PLA über die Verfügbarkeit und Funktionalität aufgenommen wird.

1. Einleitung/Präambel 2. Grundlagen der Vereinbarung 3. Beschreibung des IT-Service 3.1 Bezeichnung und Kurzbeschreibung 3.2 Nutzen für den Kunden 3.3 Anwenderfunktionalitäten 3.4 Service-Qualitäten 3.5 Servicezeiten und Support 3.6 Bedingungen der Servicenutzung 3.7 Kosten und Vergütung 4. Kommunikation und Berichtswesen 4.1 Service Level Berichte 4.2 Service Review-Treffen 4.3 Regelungen zur Änderung der Vereinbarung 4.4 Konfliktlösung und Eskalationswege 4.5 Kontaktdaten/Ansprechpartner 5. Juristischer Gegenstand der Vereinbarung 5.1 Gerichtsstand 5.2 Haftung und Gewährleistung 5.3 Schadenersatz 5.4 Anwendbares Recht 5.5 Teilnichtigkeit von Regelungen 6. Unterschriften 7. Anhänge Abbildung 7: Vergleich zum SLA: Gleich bleibende Punkte sind hervorgehoben (Fettdruck)

Bundesamt für Sicherheit in der Informationstechnik

49

5 PLA-Template

Abbildung 8 zeigt eine hieraus abgeleitete Gliederung für ein PLA. Die einzelnen Aspekte dieser Gliederung werden in den anschließenden Abschnitten näher vorgestellt. Der Schwerpunkt liegt hierbei auf dem Kapitel 5.8 „Abschnitt 4: Vereinbarung des Schutzniveaus“ und den beiden folgenden Abschnitten „Abschnitt 5: Audit-Berechtigungen“ und „Abschnitt 6: Kommunikation und Berichtswesen“.

1. Einleitung/Präambel

5. Audit-Berechtigungen

1.1 Gegenstand der Vereinbarung

5.1 Gegenstand und Ausschlüsse

1.2 Ziele der Vereinbarung

5.2 Audit-Zyklen und Fristen

1.3 Versionierung des SLA

5.3 Audit-Berechtigte

2. Grundlagen der Vereinbarung 2.1 Partner

5.4 Verpflichtungen des Dienstleisters 5.5 Einbindung von Subauftragnehmern

2.2 Geltungsbereich

6. Kommunikation und Berichtswesen

2.3 Inkrafttreten, Laufzeit und Kündigung

6.1 Service-Level-Berichte

2.4 Pflichten der Partner

6.2 Service- und Security-Review-Treffen

2.5 Vertraulichkeit, Geheimhaltung und Veröffentlichung

6.3 Alarmierung

3. Beschreibung des IT-Service

6.4 Vorfallsbehandlung

3.1 Bezeichnung und Kurzbeschreibung

6.5 Regelungen zur Änderung der Vereinbarung

3.2 Nutzen für den Kunden

6.6 Konfliktlösung und Eskalationswege

3.3 Anwenderfunktionalitäten

6.7 Kontaktdaten/Ansprechpartner

3.4 Servicezeiten und Support 3.5 Kosten und Vergütung

7. Juristischer Gegenstand der Vereinbarung 7.1 Gerichtsstand

4. Vereinbarung des Schutzniveaus

7.2 Haftung und Gewährleistung

4.1 Schutzziele

7.3 Schadenersatz

4.2 Erweiterte Schutzziele

7.4 Anwendbares Recht

4.3 Sicherheitsgarantien

7.5 Teilnichtigkeit von Regelungen

4.4 Voraussetzungen für die Erfüllung

8. Unterschriften 9. Anhänge

Abbildung 8: Kombinierter SLA/PLA

50

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

5.5

Abschnitt 1: Einleitung/Präambel

Dieser Abschnitt kann ohne Änderung wie im SLA Abschnitt (Einleitung/Präambel) beschrieben übernommen werden. Unterabschnitt

Inhalte/Bemerkungen

Gegenstand der Vereinbarung

Benennung der vom Dienstleister für den Dienstnutzer erbrachten Dienste, inkl. Einsatzzweck des Dienstnutzers

Ziele der Vereinbarung

Motivation für den Abschluss des PLAs, Ziele der beteiligten Parteien (siehe Abschnitt 4.3).

Versionierung des PLA

Aktuelle Versionsnummer und Datum zur eindeutigen Identifizierung der PLA-Version.

Tabelle 1: PLA-Unterabschnitte im Abschnitt 1

5.6

Abschnitt 2: Grundlagen der Vereinbarung

Diese Abschnitt kann ohne Änderung wie im SLA Abschnitt (Einleitung/Präambel) beschrieben übernommen werden. Unterabschnitt

Inhalte/Bemerkungen

Partner

Benennung des Dienstleisters, des Dienstnutzers und ihrer organisatorischen Stellung zu einander (interner Dienstleister, externer Auftragnehmer, etc.) Benennung konkreter Ansprechpartner auf beiden Seiten und ihrer Rollen.

Geltungsbereich

Beschreibung des Geltungsbereichs, z. B. durch organisatorische Abgrenzung („...Dieses PLA regelt die Bereitstellung der Dienste X, Y und Z durch das Beispiel-DLZ für alle Mitarbeiter des Beispielamtes Beispielstadt...“).

Inkrafttreten, Laufzeit und Kündigung

Gültigkeitsbeginn, Laufzeit, Bestimmungen zur Verlängerung, Kündigungsrechte beider Seiten.

Pflichten der Partner

Besondere Verpflichtungen der Partner im Hinblick auf das geschlossene PLA (z. B. Nutzung bestimmter vom Kunden vorgegebener Infrastrukturen oder Dienste wie einem externen Identity Provider).

Vertraulichkeit, Geheimhaltung und Veröffentlichung

Bestimmungen zur Vertraulichkeit des PLA, ggf. Einstufungsgrad.

Tabelle 2: PLA-Unterabschnitte im Abschnitt 2

Bundesamt für Sicherheit in der Informationstechnik

51

5 PLA-Template

5.7

Abschnitt 3: Beschreibung des IT-Services

Grundsätzlich gelten die im Abschnitt Beschreibung des IT-Services vorgestellten Erklärungen mit kleineren Abweichungen. Der Hauptunterschied liegt in der Beschreibung der Service-Qualitäten, die potenziell redundant mit der Definition der Verfügbarkeit sind. Der Abschnitt „Service-Qualitäten“ kann daher entfallen, alle hier anstehenden Angaben können im Abschnitt „Vereinbarung des Schutzniveaus“ gemacht werden. Die Vereinbarung des Schutzniveaus umfasst die Garantien für Performance und Verfügbarkeit. Der SLA-Abschnitt „Bedingungen der Servicenutzung“ wird der Übersichtlichkeit halber mit dem Abschnitt „Bedingungen für die Erfüllung der Schutzziele“ zusammengefasst, da ein erheblicher Überschneidungsbereich besteht. Unterabschnitt

Inhalte/Bemerkungen

Bezeichnung und Kurzbeschreibung

Für jeden Service: - Eindeutige Bezeichnung - URLs/Schnittstellen - Kurze verbale Beschreibung

Nutzen für den Kunden

Einsatzzweck der Services beim Kunden Bedeutung der Services für die Aufgabenerfüllung (unterstützend/wesentlich)

Anwenderfunktionalitäten

Funktionen der Services aus Sicht der einzelnen Anwender. Sicherheitsdienstleistungen, die sich nicht direkt auf die Schutzziele auswirken, sondern einen direkten Mehrwert für den Anwender erbringen, wie z. B. die Spam-Filterung bei E-Mail-Diensten, gehören ebenfalls in diesen Abschnitt.

Servicezeiten und Support

Zeiten, zu denen der Service bereitgestellt werden muss (z. B. übliche Dienstzeiten)3 Kritische Zeiträume (z. B. Jahres- oder Quartalsabschluss) Leistungen des Service- und User-Help-Desks (Umfang, Zeiten, Erreichbarkeit, Reaktionszeit, Bearbeitungsdauer)

Kosten und Vergütung

Vereinbarte Preise und Abrechnungsgrundlagen

Tabelle 3: PLA-Unterabschnitte im Abschnitt 3

3 Beachtet werden sollten die Erfordernisse des Patch-Managements: Die regelmäßigen Service-Zeiten müssen ausreichend Spielraum für die Erfüllung der Anforderungen des Patch-Managements bieten, oder es müsse geeignete Konzepte für das Patch-Management im laufenden Betrieb vorliegen. 52

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

5.8

Abschnitt 4: Vereinbarung des Schutzniveaus

Die Vereinbarung des Schutzniveaus ist das eigentliche PLA. Wichtig für diesen Abschnitt ist vor allem das Bezugsobjekt der Anforderungen. Das Bezugsobjekt können Daten (z. B. bei Vertraulichkeitsanforderungen), Systeme, Kommunikationsleitungen, Anwendungen, Teile eines Systems oder Personen (Mitarbeiter, Anwender) sein. Beispielsweise muss bei Vertraulichkeitsanforderungen klar sein, auf welche Daten sie sich beziehen. Dabei muss der Versuchung widerstanden werden, den Bereich zu allgemein zu fassen, um keine unrealistischen Vorgaben zu erzeugen („alle Daten sind streng vertraulich“, „100 % Uptime“), die den Wert der gesamten Vereinbarung schwächen. Auf der obersten Ebene – und aus Kundensicht – sind die Sicherheitsanforderungen dabei meistens an Daten geknüpft (Vertraulichkeit, Integrität, Verfügbarkeit). Anwendungen, Systeme und Personen kommen als Bezugsobjekt der Sicherheitsanforderungen meist erst in den mittelbar aus diesen Zielen abgeleiteten detaillierten Anforderungen vor. Unterabschnitt

Inhalte/Bemerkungen

Schutzziele

Kundenanforderungen an die Vertraulichkeit Kundenanforderungen an die Integrität Kundenanforderungen an die Verfügbarkeit Rangfolge der Sicherheitsziele zu weiteren Details siehe 5.8.1

Erweiterte Schutzziele

Darstellung weiterer für das Anwendungsszenario relevante Schutzziele, z. B. Authentizität, Anonymität, Nachvollziehbarkeit, Revisionssicherheit zu weiteren Details siehe 5.8.2

Sicherheitsgarantien

Vereinbarung einzelner Sicherheitsgarantien Dieser Abschnitt bildet den eigentlichen „Hauptteil“ des PLAs, er kann entsprechend umfangreich und komplex werden. zu weiteren Details siehe 5.8.3

Voraussetzungen für die Erfüllung

Bedingungen, unter denen der Service durch den Kunden sicher genutzt werden kann. Neben den im Abschnitt 3.4.2 (Bedingungen der Servicenutzung) angegebenen objektiven Bedingungen für die Service-Nutzung müssen vor allem die „Beistellungsverpflichtungen“ des Dienstnutzers aufgeführt werden, die für eine Einhaltung der Sicherheitsgarantien durch den Dienstleister notwendig ist. Insbesondere können hier externe Bedingungen, wie die Verfügbarkeit und Funktion eines vom Dienstnutzer spezifizierten externen Authentifizierungsdienstes oder eines Speicherdienstes aufgeführt werden.

Tabelle 4: PLA-Unterabschnitte im Abschnitt 4

Bundesamt für Sicherheit in der Informationstechnik

53

5 PLA-Template

5.8.1 Sicherheitsziele Die Sicherheitsziele sollten die Ansprüche an das Schutzniveau auf höchster Ebene beschreiben. Grob vergleichbar vom Abstraktionsgrad ist die Sicherheitsleitlinie einer Organisation (vgl. Maßnahme M 2.192 aus den IT-Grundschutzkatalogen [Grundsch 2009]) – mit dem Unterschied, dass die fachlichen Sicherheitsziele der Anwendung bzw. des Services beschrieben werden, und die Beschreibung damit spezifischer erfolgen kann. Neben der Definition der Sicherheitsziele selbst müssen unbedingt die Prioritäten der Schutzziele definiert werden. Beispiel: „Die Schutzziele Vertraulichkeit und Integrität sind gleichwertig und haben Vorrang vor der Verfügbarkeit“. Vertraulichkeit Die Vertraulichkeitsanforderungen sollten immer möglichst explizit angegeben werden. Statt einem in diesem Rahmen nicht definierten Wert wie „hohe Vertraulichkeit“ oder „geheim“ müssen vor allem zwei Fragen beantwortet werden: 1. Unter welchen Umständen ist die Vertraulichkeit gewahrt? Diese Frage übersetzt sich meist mit: „Welche Personen dürfen auf welche Inhalte Zugriff erlangen.“ Dabei sollten unbedingt alle notwendigen Zugriffsmöglichkeiten aufgeführt werden. Oft vergessen werden implizite Zugangsmöglichkeiten: Systemadministratoren, technische Hilfskräfte mit physischem Zugang zu Festplatten oder Bändern, Personal mit der Möglichkeit zur Rechtevergabe. 2. Wie hoch soll der Aufwand zum Bruch der Vertraulichkeit sein? Wann wird eine starke Verschlüsselung benötigt? Gegen wen? Soll für den Zugriff durch Administratoren ein Vier-Augen-Prinzip erzwungen werden? Werden Protokolle über Berechtigungsänderungen und Zugriffe geführt? Zur Verdeutlichung ist im Folgenden ein Beispiel für ein Dokumentenmanagement-System mit vertraulichen Dokumenten auszugsweise wiedergegeben: Nur die in der Berechtigungsliste eines Dokuments explizit aufgeführten und im Berechtigungsmanagement einsehbaren Personen dürfen direkten Zugriff auf die Daten erhalten. Bei dem Zugriff von technischem Personal auf die Daten bzw. Datenträger muss ein Vier-Augen-Prinzip technisch erzwungen werden; jeder einzelne Zugriff ist dem Kunden zur Kenntnis vorzulegen. Diese Anforderung gilt für den Zugriff über die Anwendung oder das System sowie für die physische Datenträger (Festplatten, Bänder), auch bei einem Defekt. Aus der Kontrolle entlassen werden die Medien nur bei sicherer Datenverschlüsselung oder nach sicherer Löschung. Integrität Im Rahmen des PLA sollten hier zuerst fachliche Anforderungen an die Datenintegrität definiert werden, falls sie sich identifizieren lassen. Diese Anforderungen können stark variieren und sind

54

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

nicht in jedem Fall vorhanden. Beispielsweise könnte für eine Abfrage von Kontodaten die Bedingung aufgestellt werden, dass gleichzeitig abgefragte Konten auch Daten vom selben Zeitpunkt enthalten und keine Transaktionen zwischen den abgefragten Konten offen sind. Eine ähnliche Problematik kann sich z. B. beim Wiedereinspielen von Backups ergeben – kann der Service bereits mit Teildaten gefahren werden oder nicht? Andere Integritätsanforderungen werden aus PLA-Sicht oft schon implizit erzwungen, z. B. die Systemintegrität durch die Vertraulichkeits- und Funktionsanforderungen. Die Integrität der Daten wird bei einer Verschlüsselung zwar oft „mitgeliefert“ (technisch durch Prüfsummen), sollte aber trotzdem explizit erwähnt werden. Folgende Fragen müssen beantwortet werden: 1. Was bedeutet Integrität der Daten? Muss die Integrität in Referenz zu externen Datenquellen gehalten werden? Wie kann der Dienstleister die Integrität von externen Referenzen sicherstellen? 2. Welche Priorität hat die Integrität gegenüber der Verfügbarkeit? Müssen bei einer festgestellten Integritätsverletzung sofort alle Teile des Services gestoppt werden? Verfügbarkeit Die Verfügbarkeitsanforderungen müssen hier nur in so weit behandelt werden, als sie noch nicht im SLA-Teil der Vereinbarung angegeben wurden. Idealerweise sollten die Anforderungen aber nur an einer Stelle dokumentiert sein; in einem kombinierten SLA/PLA wird empfohlen, die Sicherheitsanforderungen und damit auch die Verfügbarkeit im PLA zu bündeln. Die Angaben hier entsprechen weitgehend den Angaben im SLA-Abschnitt „Service-Qualitäten“ (siehe Abschnitt 3.4.2). Hinzu kommt die Priorisierung gegenüber den anderen Sicherheitszielen. Die Verfügbarkeitsanforderungen können idealerweise in drei Schritten definiert werden: 1. Definition einer Messung, deren Ergebnis „Verfügbar“ oder „nicht Verfügbar“ ist. 2. Angabe, wer die Messung durchführt, wie oft das geschieht und wie die Ergebnisse zu bewerten sind. Idealerweise sollte eine Methode gefunden werden, bei der das Ergebnis von beiden Seiten akzeptiert wird. 3. Aus der Messwerten abgeleitete Angaben über die minimale Verfügbarkeit (z. B. maximale Ausfallzeiten, siehe Abschnitt „Service-Qualitäten“). Nicht übersehen werden dürfen dabei die Randbedingungen: - Das Mengengerüst, unter dem diese Bedingungen einzuhalten sind, muss angegeben bzw.

referenziert sein (dies ist oft schon Teil der funktionalen Beschreibung). - Gerade bei komplexen Services kann es Zwischenstufen zwischen „verfügbar“ und „nicht

verfügbar“ geben, meist ist dies über die Antwortzeit definiert. Auch hier können maximale Zeiten für eine solche „Teilverfügbarkeit“ angegeben werden. - Das Verhältnis zu geplanten und ungeplanten Wartungsarbeiten muss explizit definiert

werden. Ein Service ohne regelmäßige geplante Wartungszeiten ist in der Praxis nur extrem aufwendig oder gar nicht umzusetzen. Häufige Wechselwirkungen ergeben sich

Bundesamt für Sicherheit in der Informationstechnik

55

5 PLA-Template

z. B. oft mit den Anforderungen an das Patch-Management (schnelles Einspielen kritischer Patches).

5.8.2 Erweiterte Schutzziele Die drei Standard-Schutzziele decken bestimmte Teilbereiche der Informationssicherheit nicht immer vollständig ab. Für manche Anforderungen müssen daher erweiterte Schutzziele in Betracht gezogen werden. Die folgenden Schutzziele decken die meisten denkbaren Fälle ab. Authentizität Authentizitätsanforderungen beziehen sich nicht nur auf Personen, sondern auch auf Dienste. Im SOA-Umfeld bzw. bei netzwerkzentrischen Diensten muss die Authentizität eines Dienstes immer hinreichend geprüft werden; dies ergibt sich bereits implizit aus den Standardanforderungen. Im PLA explizit definiert werden sollte, wenn spezielle Überprüfungsmethoden der Authentizität vorgegeben werden sollen. Anonymität Anforderungen an die Anonymität eines Dienstes kommen häufig aus den Anforderungen des Datenschutzes – sie sollten dann auch unter dem Stichwort Datenschutz geregelt werden. Eine explizite Regelung empfiehlt sich dann, wenn der Anonymität eine besondere Rolle zukommt (z. B. bei Kommunikationsanforderungen im Compliance Management) und diese auch nach außen getragen wird bzw. getragen werden muss. Nachvollziehbarkeit (accountability, non-repudiation) Die Nachvollziehbarkeit besteht aus zwei Teilzielen, die im Englischen deutlicher getrennt werden: 1. Zurechenbarkeit („accountability“): Durchgeführte Handlungen müssen einer bestimmten Person zugeordnet werden können. 2. Nichtabstreitbarkeit („non-repudiation“): Das Abstreiten der Handlungen durch eine Person darf nicht möglich sein. Die erste Forderung ist fast universell und sollte Grundvoraussetzung für die meisten Vorgänge sein. Insbesondere bei Administrationstätigkeiten und der Berechtigungsverwaltung wird die Nachvollziehbarkeit oft außer Acht gelassen. Die zweite Forderung nach Nichtabstreitbarkeit ist stärker, wird aber üblicherweise seltener benötigt, so z. B. bei elektronischen Vertragsabschlüssen. Revisionssicherheit Der Begriff „Revisionssicherheit“ bezieht sich fast ausschließlich auf Archivsysteme bzw. Protokollierungssubsysteme. Die Revisionssicherheit wird insbesondere dann gefordert, wenn handels- oder steuerrechtliche Anforderungen des Handelsgesetzbuches, der Grundsätze ordnungsgemäßer DV-gestützter Buchführungssysteme (GoBS) oder anderer gesetzlicher Regelungen umgesetzt werden sollen. 56

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

Wichtigster Bestandteil ist der Schutz der Archiv- oder Protokolldaten vor Veränderung oder vorzeitiger Löschung. Dabei sollte bedacht werden, wie die Revisionssicherheit durch den Anbieter hergestellt werden kann. Klassisch wird Revisionssicherheit oft als Synonym für eine Archivierung auf einmalig beschreibbaren optischen Medien (WORM) angesehen, doch diese Auslegung ist zu eng: mittels kryptographischen Verfahren (Signaturen, signierte Zeitstempel) lässt sich eine Revisionssicherheit auch in anderem Rahmen herstellen. Wenn Revisionssicherheit gefordert wird, sollten die Bedingungen möglichst explizit definiert werden: Welche Daten müssen ab welchem Zeitpunkt für wie lange gesichert werden? Datenschutz (privacy) Für die Einhaltung von Datenschutzanforderungen kommt es darauf an, die schutzbedürftigen Daten auch zu identifizieren. Als erstes sollte in diesem Abschnitt daher explizit definiert welche, ob und wo personenbezogene Daten zu erwarten sind. Anschließend sollte die Verpflichtung aller relevanten Personen auf die Einhaltung der relevanten Datenschutzregelungen gefordert werden. Die relevanten Datenschutzregelungen sind üblicherweise mindestens § 5 und § 9 BDSG sowie die zutreffenden Landesdatenschutzgesetze. Je nach Einsatzgebiet kann die Einhaltung von wesentlich mehr Regelungen notwendig sein (z. B. Fernmeldegeheimnis, Sozialdatenschutz) – daher sollte der Datenschutzbeauftragte für die Formulierung hinzugezogen werden. Der Ausschluss der Auftragsdatenverarbeitung im nicht-europäischen Ausland (außerhalb des Geltungsbereichs der Richtlinie 95/46/EG) ergibt sich im Prinzip automatisch aus den gesetzlichen Bedingungen, sollte aber explizit formuliert werden. Dies schließt dann den Export der Daten über Konstrukte wie die „Safe Harbor“-Provisionen aus. Die Liste der relevanten Personen für die Verpflichtung umfasst: - sämtliche Personen, die potenziell Zugriff auf personenbezogene Daten haben - sämtliche Subauftragnehmer, die eine Auftragsdatenverarbeitung mit diesen Daten durchführen

sowie deren Subauftragnehmer. Zur Auftragsdatenverarbeitung gehört auch die Datenvernichtung.

5.8.3 Sicherheitsgarantien Unter dem Stichwort „Sicherheitsgarantien“ werden zusätzliche, explizite Garantien auf technischer Ebene gefordert. Dies muss im Text auch dargelegt werden, z. B. mittels folgender Formulierung: Die im Folgenden aufgeführten Garantien sind explizit vereinbarte Sicherheitsmerkmale, die entweder eine spezielle Umsetzung der in den Sicherheitszielen vereinbarten Ziele vorgeben oder zusätzliche Maßnahmen fordern. Es liegt in der Verantwortung des Dienstleisters, über die hier vereinbarten expliziten Maßnahmen hinaus alle in den Sicherheitszielen vereinbarten Eigenschaften mittels passender Maßnahmen einzuhalten.

Bundesamt für Sicherheit in der Informationstechnik

57

5 PLA-Template

In der Praxis bewährt hat sich ein pragmatischer Ansatz, d. h. explizite Formulierungen bereits von den Schutzzielen abgedeckter Tatsachen werden nur für Punkte benötigt, bei denen häufig Missverständnisse oder Problem auftauchen. Es sollte ebenfalls eine klare Trennung zu den Funktionalitäten des Dienstes eingehalten werden. So sind z. B. der Einsatz eines Spam-Filters bei einem Mail-Dienst oder der Einsatz von VirenScannern für die Daten (z. B. bei Web-Gateways oder in Dokumentenmanagement-Systemen) keine Sicherheitsgarantien im Sinne des PLA, sondern funktionale Eigenschaften des Dienstes. Der Einsatz eines Virenscanners oder Integritätscheckers für die Serverinfrastruktur des Dienstes hingegen wäre eine Sicherheitsgarantie im Sinne eines PLA. Sicherheitsfunktionen sollten immer dann als Teil der Funktionsdefinition abgebildet werden, wenn sie für die Unterstützung der grundlegenden Sicherheitsziele durch den Dienstleister nicht relevant sind. Die folgenden Abschnitte zeigen die am häufigsten benötigten Sicherheitsgarantien, gruppiert nach Themengruppen („Domänen“): Einhaltung von Standards Hier kann die Einhaltung von extern definierten Sicherheitsstandards wie z. B. IT-Grundschutz gefordert werden. Die Einhaltung kann aus zwei Gründen gefordert werden, die beide wohlüberlegt sein sollten: Externe Anforderungen Bei Regelungen oder Standards, die vom Service-Nutzer selbst erfüllt werden müssen, müssen diese üblicherweise auch direkt an seine Dienstleister weitergegeben werden (z. B. aufgrund von externen Anforderungen wie PCI-DSS). Da die Einhaltung eines umfassenden Standards einen erheblichen Aufwand darstellt, sollten – wenn die Anforderungen durch das PLA bereits klar genug kommuniziert sind – Alternativen in Betracht gezogen werden, die sich durch eine Aufteilung des Dienstes erreichen lassen können. Die Forderungen nach Einhaltung hängen meist an bestimmten Daten: Personendaten z. B. beim Datenschutz oder Kartenhalterdaten bei PCI-DSS. Oft lassen sich die Bereiche, in denen der Standard eingehalten werden muss, stark einschränken, indem die Sicherheitsanforderungen „entkoppelt“ werden. Dies geschieht meist über die Kombination von Verschlüsselung und Systemtrennung (vgl. Abschnitt 4.5.1). Interne Anforderungen Die Einhaltung wird vom Servicenutzer gewünscht, um eine eindeutige Grundlage für die Sicherheitsanforderungen zu haben. Eine explizite Zertifizierung ist in diesem Fall immer sinnvoll, um späteren Diskussionen über die Umsetzung aus dem Wege zu gehen. Formulierungen wie „eine Zertifizierung wird angestrebt“ sollten vermieden werden. Gerade der für den Einsatz in der Bundesverwaltung in Frage kommende Standard ISO 27001 auf Basis IT-Grundschutz ist noch stark auf den internen Einsatz innerhalb einer Organisation ausgelegt. Eines der größten Probleme in der Praxis ist die meist fehlende Kommunikation des Schutzbedarfs der Daten. Eine entsprechende Feststellung und Kennzeichnung sowie der Austausch dieser Daten müssen hier festgelegt werden. 58

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

Patch-Management Ein geregeltes Patch-Management gehört eigentlich zu den „selbstverständlichen“ Pflichten eines Dienstleisters. Trotzdem treten hier die meisten Reibungsverluste im praktischen Betrieb auf. Oft ist z. B. unklar geregelt, welche Auswirkungen Ausfallzeiten aufgrund kritischer Patches auf die Verfügbarkeitsberechnung haben, wer den Aufwand für zusätzliche Arbeiten bei außerplanmäßigen Patches trägt, und ob und wie der Dienstnutzer informiert wird. Eine gute Regelung sollte die folgenden Punkte umfassen: - Der Dienstleister ist in der Verantwortung, das Erscheinen sicherheitskritischer Patches sowie

das Bekanntwerden von Schwachstellen für die von ihm eingesetzten Produkte zeitnah zu verfolgen und zu reagieren. - Kriterien für die Kategorisierung von Patches - Fristen, in denen kritische und weniger kritische Patches getestet und eingepflegt werden - Die Regelung der Kommunikation und der Terminabsprachen von Patches – also z. B. eine

Vorab-Information des Dienstnutzers bei bekanntgewordenen Schwachstellen und Patches sowie ein etwaiges Mitbestimmungsrecht für den Patch-Zeitraum. - Entscheidungsbefugnisse für das Einspielen von Sicherheitspatches

Datensicherung Sofern der Dienstleister gegenüber dem Dienstnutzer Services erbringt, bei denen persistente Daten beim Dienstleister vorgehalten werden, müssen für die jeweils verwendeten Datentypen die Anforderungen an die Datensicherung durch den Dienstleister definiert werden. Dazu gehören in Analogie zur Maßnahme M 6.34 aus den IT-Grundschutz-Katalogen: - die Spezifikation der vom Dienstleister zu sichernden Daten - die Verfügbarkeitsanforderungen an die Daten - ggf. Überlegungen zum Rekonstruktionsaufwand der Daten ohne Sicherung - Volumina (Daten, Änderungen pro Zeiteinheit, Änderungszeitpunkte) - Aufbewahrungsfristen - Vertraulichkeitsanforderungen an die Datensicherung - Integritätsanforderungen an die Datensicherung

Authentisierung Für die Authentisierung existieren verschiedene Verfahren mit unterschiedlichen Sicherheitsniveaus, wie z. B. Passwörter, Einmalpasswörter, Software-Zertifikate und Chipkarten. Im Rahmen des PLAs können Regelungen erfolgen, welche Funktionen oder Daten mit welchen Authentisierungs-Verfahren zugänglich sein dürfen. In einer SOA betrifft dies primär die Sicherheitsparameter für die Kommunikation beim Diensteaufruf (Authentisierung des Dienstes und Authentisierung des Nutzers). Das PLA kann jedoch darüber hinaus auch Vorgaben für die Bundesamt für Sicherheit in der Informationstechnik

59

5 PLA-Template

Authentisierung in anderen Bereichen machen (z. B. beim Systemzugang durch Administratoren, beim Aufruf einer web-basierten Administrationsoberfläche etc.) Sichere Löschverfahren von Daten Die sichere Löschung aller unverschlüsselt4 gespeicherten Daten sollte eindeutig geregelt werden. Festgelegt werden müssen dabei: - Akzeptierte Verfahren zur sicheren Löschung, nach Datenträgertyp (magnetisch, optisch, Flash) - Akzeptierte Verfahren zur physischen Vernichtung der Datenträger, ebenfalls nach

Datenträgertyp - Bedingungen für die (temporäre) Lagerung und den Transport solcher Datenträger.

Verschlüsselung Forderungen nach sicherer Verschlüsselung sind Bestandteil praktisch jedes PLAs. In diesem Abschnitt wird definiert, wie eine sichere Verschlüsselung definiert ist. In der Praxis genügt die Definition eines Mindeststandards, der als „sicher“ bezeichnet wird. Die Definition verschiedener Stärken ist in der Praxis selten sinnvoll.5 Der akzeptierte Mindeststandard besteht aus folgenden Punkten: - Akzeptierte Hash- und Verschlüsselungsverfahren

Die Angabe kann explizit durch die Angabe einer Reihe von Algorithmen oder impliziert durch den Rückgriff auf einen Standard gesetzt werden. In vielen Bereichen hat die Angabe eines Standards wie z. B. FIPS 140-2 den Vorteil, dass sie gleichzeitig eine erhöhte Kompatibilität mit anderen Anforderungen bietet. Eine „dynamische“ Möglichkeit existiert hier prinzipiell nicht, da die Umstellung von Verschlüsselungsverfahren in vielen Fällen ein sehr hohes Hindernis darstellt. Verschlüsselungsverfahren sollten daher so gewählt werden, dass eine Änderung während der Vertragslaufzeit nicht notwendig wird. Ist eine Änderung absehbar, z. B. weil gerade neue Standards entwickelt werden (wie zum Zeitpunkt der Erstellung dieser Studie bei dem laufenden Wettbewerb für ein neues sicheres HashVerfahren durch das NIST), sollte die zukünftige Ablösung als explizite Forderung mit aufgenommen werden. - Mindeststärke der kryptographischen Verfahren

Die Angabe der Stärke erfolgt oft in Bit mit zwei Werten für symmetrische und asymmetrische Kryptographie (z. B. „128 Bit symmetrisch“ oder „2048 Bit asymmetrisch“). Tatsächlich muss die Mindeststärke aber pro Algorithmus und Betriebsart6 angegeben werden. 4 Bei sicher verschlüsselten Daten genügt üblicherweise die sichere Löschung der Schlüssel statt der Daten selbst. 5 Angriffe auf die Verschlüsselung finden fast immer auf Implementierungsebene statt und sind damit nicht von einer definierten Stärke abhängig. Die Einhaltung einer minimalen Stärke, die hoch genug ist, um einen direkten Angriff abzuwehren, ist dagegen meist sehr „günstig“. 6 Mit Betriebsart sind die Art (Stream oder Block) bzw. der Modus bei Blockchiffren gemeint (CBC, ECB) gemeint. Die Betriebsart macht häufig einen Sicherheitsunterschied. So ist z. B. der ECB für viele Anwendungsfälle auch bei ansonsten sicheren Algorithmen unsicher, da er gleiche Blöcke jeweils gleich verschlüsselt. 60

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

Theoretisch wünschenswert wäre eine Angabe über den „Work-Faktor“ (den Aufwand für das Brechen einer Verschlüsselung); diese sollte auch als Zielvorstellung aufgenommen werden. In der Praxis bestehen aber hinreichend oft Differenzen über den realen WorkFactor, gerade auch bei neu bekanntgewordenen mathematischen Angriffen, so dass eine zusätzliche explizite Angabe zu empfehlen ist. Bei der Angabe der Mindeststärke sollten die Vertragslaufzeiten bedacht werden. Mathematische Angriffsmethoden werden mit der Zeit weiterentwickelt; ebenso werden die Rechenzeiten von Brute-Force-Angriffen günstiger. Als Faustregel bietet sich an, nur Algorithmen zuzulassen, die auch bei einer Reduzierung des Work-Factors um 7-10 Größenordnungen noch als sicher zu bezeichnen sind. - Einsatzfelder für die kryptographischen Verfahren

Hier werden die für ein Verfahren erlaubten Einsatzfelder definiert: z. B. welche HashVerfahren für eine Dokumentsignatur erlaubt sind, und welche als Einweg-Hash für Passwörter. - Anforderungen an die Implementierung

Hier können einzuhaltende Produktstandards definiert werden, wie z. B. FIPS 140-2, oder Zertifizierungen nach ITSEC bzw. Common Criteria. Da die meisten Angriffe auf verschlüsselten Daten Implementierungsfehler ausnutzen, wird die einfache Angabe von Algorithmen oft als nicht ausreichend angesehen. - Schlüsselverteilung

Die Abläufe zur Schlüsselverteilung, also die Bedingungen für die Zusammenarbeit müssen hier definiert werden. Gemeinsame PKI-Strukturen, akzeptierte Trust-Stellungen und die Verantwortung für die Funktionsfähigkeit der Trust-Verwaltung müssen geregelt werden. Protokollierung Die Protokollierung selbst ist Grundlage für die Erkennung von Sicherheitsvorfällen. - Welche Ereignisse werden protokolliert?

Die Protokollierung von Zugriffen wird häufig gefordert, um die Verfolgung von Verletzungen sämtlicher Schutzziele nachvollziehen zu können. Dazu bedarf es der Protokollierung sämtlicher Zugriffe auf die Daten. Problematisch ist hier sehr häufig die Protokollierung administrativer Zugriffe außerhalb des eigentlichen Interfaces. - Wer hat Zugriff auf die Protokolldaten? - Erhält der Kunde Zugriff auf die Protokolldaten? Wie schnell kann er auf die Daten zugreifen?

Soll eine Chance bestehen, die Protokolldaten für eine nachträgliche Analyse von Sicherheitsvorfällen heranziehen zu können, muss die Forderung nach einer Synchronisierung sämtlicher beteiligter Systeme (Dienstnutzer und Dienstleister) untereinander bzw. mit einer normativen Zeitquelle enthalten sein.

Bundesamt für Sicherheit in der Informationstechnik

61

5 PLA-Template

Berechtigungsreview Um die Berechtigungen der eigenen Nutzer mit einem Soll-Zustand abgleichen zu können, bedarf es regelmäßiger Berechtigungs-Reviews. Die Verfahren und Rollen für einen regelmäßigen Berechtigungs-Review sollten hier festgelegt werden.

5.9

Abschnitt 5: Audit-Berechtigungen

Die für eine Kontrolle der Einhaltung der vereinbarten Sicherheitsgarantien notwendigen Überprüfungen müssen dem Dienstnutzer (der nutzenden Organisation) selbst oder einem unabhängigen, vom Nutzer beauftragten Dritten ermöglicht werden. Audits kommen in zwei Varianten vor: Zum einen als präventive, regelmäßige Audits bestimmter Stichproben und zum anderen zielgerichtet und tief gehend nach spezifischen Hinweisen auf Probleme – typischerweise ein Konfliktfall. Unterabschnitt

Inhalte/Bemerkungen

Gegenstand und Ausschlüsse

Gegenstand der Audit-Berechtigungen (Systeme, Anwendungen, Prozesse) und Ausschlüsse (z. B. aus berechtigtem Interesse des Dienstleisters am Schutz von Betriebsgeheimnissen – solche Ausnahmen müssen dann möglichst präzise vereinbart und begründet werden).

Audit-Zyklen und Fristen

Häufigkeit der Audits (z. B. mindestens einmal jährlich) Ankündigungsfristen, ggf. unangekündigte Audits

Audit-Berechtigte

Befugter Personenkreis (z. B. IT-Sicherheitsbeauftragter des Dienstnutzers, externe Auditoren) und Anforderungen an die Auditoren (z. B. Qualifikation, Sicherheitsüberprüfung)

Verpflichtungen des Dienstleisters Unterstützungsverpflichtungen durch den Dienstleister (Bereitstellung relevanter Unterlagen, Lesezugriff auf Systemkonfigurationen). Behandlung von Audit-Ergebnissen Einbindung von Subauftragnehmern

Benennung der Subauftragnehmer für von den AuditBerechtigungen umfassten Systeme, Anwendungen und Prozesse Einräumung gleichartiger Befugnisse für Audits bei den Subauftragnehmern

Tabelle 5: PLA-Unterabschnitte im Abschnitt 5

Für Netzwerkservices empfiehlt es sich, zusätzlich eine Vereinbarung über die Möglichkeit angekündigter oder unangekündigter Tests von Netzwerkseite her zu treffen, die keiner Genehmigung bedürfen. Üblicherweise werden für die Zeitdauer solcher Tests Einschränkungen in den Verfügbarkeitsgarantien des Dienstleisters vereinbart.

62

Bundesamt für Sicherheit in der Informationstechnik

PLA-Template 5

5.10 Abschnitt 6: Kommunikation und Berichtswesen Grundsätzlich gelten hier dieselben Grundsätze wie in SLAs, siehe Abschnitt (Seite 29), mit folgenden Ergänzungen: Die Service-Review-Treffen werden um den Review von Security-Belangen erweitert. Der Security Review beinhaltet die Diskussion von Erkenntnissen aus Vorfällen sowie die Vereinbarung von Maßnahmen aufgrund der Änderung von Rahmenbedingungen (gebrochene kryptographische Methoden, neue Angriffsarten, neu bekannt gewordene Schwachstellen u. ä.). Zusätzlich müssen hier die beiden Punkte Alarmierung und Vorfallsbehandlung geregelt werden. Unterabschnitt

Inhalte/Bemerkungen

Service-Level-Berichte

Berichtszyklen Berichtsempfänger inkl. Kontaktdaten Berichtsinhalte

Service- und Security-ReviewTreffen

Termine/Zeiträume Teilnehmer und Funktion Inhalte Nachverfolgung der Ergebnisse

Alarmierung

Anforderungen an die Überwachung Kategorien zu meldender Ereignisse/Vorfälle Meldungsempfänger inkl. Kontaktdaten Meldungsweg, ggf. abhängig von der Kategorie

Vorfallsbehandlung

Maßnahmen zur Erfassung von Sicherheitsvorfällen Kommunikationsschnittstelle für Vorfallsmeldungen (in beide Richtungen vom Dienstleister zum Dienstnutzer und umgekehrt) Entscheidungsbefugnisse für die Vorfallsbehandlung Berichte über den Bearbeitungsfortschritt Eskalationsstufen Dokumentation Unter diesem Punkt kann auch die Bearbeitung von kritischen Patches im Patch-Management mit aufgenommen werden. Das Bekanntwerden kritischer Schwachstellen ist auch als Sicherheitsvorfall zu werten – die Abläufe sind dann identisch.

Regelungen zur Änderung der Vereinbarung

Verfahren zum Änderungsmanagement des PLA Ansprechpartner auf beiden Seiten Entscheidungsbefugnisse

Bundesamt für Sicherheit in der Informationstechnik

63

5 PLA-Template

Unterabschnitt

Inhalte/Bemerkungen

Konfliktlösung und Eskalationswege

Vereinbarte Wege zur Konfliktlösung Eskalationsstufen und Ansprechpartner

Kontaktdaten/Ansprechpartner

Ansprechpartner und Kommunikationspartner beider Seiten mit Rolle, Name und relevanten Kontaktdaten

Tabelle 6: PLA-Unterabschnitte im Abschnitt 6

5.11 Abschnitt 7: Juristischer Gegenstand der Vereinbarung Diese Abschnitt kann ohne Änderung wie im SLA Abschnitt beschrieben (Seite 29) beschrieben übernommen werden. Die Ausformulierung sollte durch die jeweiligen Rechtsabteilungen erfolgen. Unterabschnitt

Inhalte/Bemerkungen

Gerichtsstand

Vereinbarter Gerichtsstand

Haftung und Gewährleistung

Regelungen zur Haftung und Gewährleistung Haftungsbeschränkungen

Schadenersatz

Regelungen zum Schadenersatz Vertragsstrafen

Anwendbares Recht

Vereinbartes Recht

Teilnichtigkeit von Regelungen

Salvatorische Klausel

Tabelle 7: PLA-Unterabschnitte im Abschnitt 7

5.12 Abschnitt 8: Unterschriften Diese Abschnitt kann ohne Änderung wie im SLA Abschnitt beschrieben (Seite 30) beschrieben übernommen werden.

64

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6

6

Protection Level Management – PLM

6.1

Der PLM-Prozess – Einleitung

In Kapitel Service Level Management nach ITIL® V3 wurde der Prozess Service Level Management beschrieben. Hierauf aufbauend wurde in der Folge eine mögliche Struktur von Service Level Agreements entwickelt. Diese Struktur wurde schließlich unter Betrachtung verschiedener Szenarien zwischen Service Providern und Service Consumern sowie unter Berücksichtigung von Sicherheitszielen und kontrollierender Maßnahmen erweitert. Diese Erweiterungen passen - wie in Kapitel Gliederung beschrieben – zum größten Teil in die Grundstruktur eines SLA hinein – sie konkretisieren die Sicherheitsanforderungen für alle vereinbarten Services. Eine analoge Aussage lässt sich auch zum Prozess der Steuerung von SLAs und PLAs treffen: Während generell der Service Level Management Prozess auch für die Steuerung von Protection Level Agreements geeignet ist, gibt es in der Durchführung Besonderheiten zu beachten bzw. Schwerpunkte zu setzen. Der wichtigste Unterschied macht sich in der Überwachung von PLAs bemerkbar. Wie im letzten Kapitel gezeigt, bewegen sich die meisten Zusicherungen in einem Bereich, den der Kunde nicht direkt messen kann. Die Überwachung ist daher meist nur indirekt oder retrospektiv möglich. Insgesamt erfordert die Überwachung von PLA-Parametern eine aktivere Rolle des Kunden. In diesem Kapitel werden daher die folgenden fünf Verfahren als Bestandteil des eng am Service Level Management (SLM) orientierten Prozesses Protection Level Management (PLM) näher vorgestellt:

Abbildung 9: Verfahren im Protection Level Management

Bundesamt für Sicherheit in der Informationstechnik

65

6 Protection Level Management – PLM

6.2

Vergleich SLM und PLM

In nachstehender Tabelle werden die in Kapitel 2.2 Service Level Management nach ITIL® V3 kurz beschriebenen Verfahren des Service Level Managements mit den zusammengefassten Verfahren des Protection Level Managements verglichen: Verfahren im SLM

Verfahren im PLM

Entwicklung von Vorlagen für SLA und anderer Wie in Kapitel 5 PLA-Template gezeigt, gelten Dokumente die wesentlichen Teile eines SLA auch für einen PLA. Die sicherheitsspezifischen Ergänzungen des SLA zu einem PLA sind analog des SLMProzesses ebenfalls Bestandteil des PLM – Prozesses, werden jedoch hier nicht weiter dargestellt. Ermittlung, Dokumentation und Vereinbarung Anforderungen an PLAs müssen aus Sicht des von Anforderungen an neue IT-Services und die Kunden erhoben und dokumentiert werden. Dies Erstellung von Service Level Requirements geschieht im Verfahren Ermittlung von Schutzanforderungen innerhalb des Kapitel Fehler: Referenz nicht gefunden. Der auf Basis der Anforderungen abzuschließende PLA wird innerhalb von Kapitel 6.5.2 im Verfahren Vereinbarung von PLAs und Absicherung beschrieben. Überwachung der Serviceleistung unter Berücksichtigung der in SLAs vereinbarten Leistungen

Die Überwachung der zugesagten Sicherheitsgarantien erfordert gegenüber der Überwachung von SLA-Parametern eine aktivere Rolle des Kunden bei der Klärung von Fakten – z.B. durch Audits. Das Verfahren ist im Kapitel 6.5.3 Überwachung von PLAs beschrieben.

Messung und Verbesserung der Kundenzufriedenheit

Im Kontext der SLA-typischen Parameter bleibt das Verfahren analog zum SLM. Im Kontext der Sicherheitsgarantien ist die Kundenzufriedenheit keine direkte Größe. Direkte Auswirkungen der Güte der Sicherheitsvorkehrungen auf die Kundenzufriedenheit sind nur in negativer Weise zu erwarten; bei eingetretenen Sicherheitsvorfällen. Kundenzufriedenheit ist eine indirekte Größe, die sich aus AuditErgebnissen sowie – bei eingetretenen Vorfällen – aus dem Incident Management ergibt.

Laufende Bewertung und Überarbeitung von unterstützenden Vereinbarungen und des Service-Umfangs

Das Review von unterstützenden Vereinbarungen im SLM bedeutet für das PLM analog die Absicherung der Vereinbarung durch

66

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6

Verfahren im SLM

Verfahren im PLM die Service Provider. Dies ist im Verfahren Vereinbarung von PLAs und Absicherung innerhalb des Kapitel 6.5.2 geregelt bzw. über die Anpassung der PLAs im Verfahren Aktualisierung/Überarbeitung von PLAs (Kapitel 6.5.4)

Erstellung von Service Reports

Die Erstellung von Service Reviews ist im Verfahren Überwachung von PLAs (Kapitel 6.5.3) beschrieben.

Durchführung von Service Reviews und die Initiierung eines Service-VerbesserungsProgramms

Die Service Reviews im PLM werden wie auch im SLM als laufende Aufgabe verstanden. Die hierfür notwendigen Aktivitäten sind im Verfahren Aktualisierung/Überarbeitung von PLAs (Kapitel 6.5.4) beschrieben.

Laufende Bewertung und Überarbeitung von Die entsprechenden Aktivitäten sind im SLAs, des Service-Umfangs und unterstützender Verfahren Aktualisierung/Überarbeitung von Vereinbarungen PLAs (Kapitel 6.5.4) beschrieben. Pflege von Kontakten und Beziehungen

Die Pflege von Kontakten und Beziehungen sind in SLM und PLM wesentlich für ein gemeinsames Service- und Qualitätsverständis. Die Aktivitäten sind im Verfahren Kontaktpflege(Kapitel 6.5.5) beschrieben.

Beschwerden und Lob

Die effiziente Bearbeitung von Lob und insbesondere Beschwerden leistet einen wichtigen Beitrag im Rahmen der Beziehungspflege zwischen Service Provider und Service Consumer. Die Aktivitäten sind daher im Verfahren Kontaktpflege(Kapitel 6.5.5) beschrieben.

Tabelle 8: Vergleich SLM/PLM

Die Übersicht zeigt, dass alle Verfahren des SLM auch im PLM Berücksichtigung finden. Der Unterschied zwischen einem Service Level Management und einem Protection Level Management ist also bezogen auf die durchzuführenden Verfahren und Aufgaben eher marginal. Insofern ist die Erkenntnis wichtig, dass das Service Level Management auch im Falle der Steuerung und Vereinbarung von Sicherheitsanforderungen geeignet ist. Die Steuerung von PLAs sollte daher in eventuell in Behörden und Einrichtungen bestehende SLM-Prozesse integriert werden. Es wird daher empfohlen, den PLM-Prozess eng am klassischen Service Level Management auszurichten. Das SLM ist ein in der Literatur häufig beschriebener Prozess, für den vielfältige Praxiserfahrungen vorliegen. Der Begriff des Service Level Managements ist etabliert und vor allem auf Kundenseite akzeptiert und bekannt.

Bundesamt für Sicherheit in der Informationstechnik

67

6 Protection Level Management – PLM

6.3

Rollen im PLM

In den nachfolgenden Verfahrensbeschreibungen werden Rollen unter zu Hilfenahme der RACIMatrix beschrieben. Die hier gewählten Rollen finden hierdurch ihre Ausprägung in Aufgaben, Verantwortlichkeiten und Kompetenzen, d. h. Rechte und Pflichten. Die Rollen im PLM entsprechen hinsichtlich ihrer Aufgaben, Verantwortungen und Kompetenzen weitestgehend den gleichlautenden Rollenbeschreibungen im Service Level Management. Welche Rollen bei Implementierung des SLM oder PLM-Prozesses einer Behörde tatsächlich umgesetzt und beschrieben werden, wäre im Einzelfall zu gestalten. Um eine möglichst allgemeingültige und sinnvolle Übersicht über die wesentlichsten Rollen zu erhalten, werden folgende Rollen innerhalb der Verfahrensbeschreibung verwendet: Rollenbezeichnung

Rollenbeschreibung

PL-Manager (PL-Mgr)

Der Protection Level Manager ist die steuernde und damit haupthandelnde Person im Prozess PLM. Analog des Service Level Managers im SLM-Prozess verantwortet der PL-Mgr den Prozess und ist für den Entwurf, die wirksame Etablierung und effiziente Fortentwicklung des PLM verantwortlich und soll Prozesseffizienz und -effektivität dauerhaft sicherstellen. Der Unterschied zwischen einem Service Level Manager und einem Protection Level Manager ist daher weniger in den grundsätzlichen Aufgaben der Prozesssteuerung und der wahrgenommenen Verantwortung zu suchen, sondern eher im Besetzungsprofil der Rolle zu suchen. Hier wird vom PL-Mgr ein tieferes Spezialwissen in Sicherheitsfragestellungen verlangt. Der Protection Level Manager ist sozusagen ein spezialisierter Service Level Manager.

Kunde

Der Kunde ist das Pendant zum PL-Mgr auf Seiten des Serviceconsumers. Er ist verantwortlich für die korrekte Definition von Qualitätsanforderungen und Empfänger von Service Berichten. Er entspricht hinsichtlich seiner Aufgaben, Verantwortungen und Kompetenzen der gleichlautenden Rollenbeschreibung im Service Level Management.

IT-Sicherheitsbeauftragter Serviceprovider (IT-Sibe SP)

Die Rolle IT-Sicherheitsbeauftragter ist zu verstehen im Sinne von „Verantwortlich für alle Sicherheitsbelange der Informationstechnik“. Sie ist daher sowohl auf Seiten des Serviceproviders als auch auf Seiten des Kunden besetzt. Die Rolle IT-Sibe wird vor allem bei Einhaltung von Ratschlägen und Informationen hinzugezogen.

IT-Sicherheitsbeauftragter Serviceconsumer (IT-Sibe SC) Fachvorgesetzer Serviceprovider (FV SP)

68

Der Fachvorgesetzte auf Seiten des Serviceproviders (FV SP) bestimmt als „Eigentümer des PLM“ die Ziele und den Gestaltungsumfang des PLM-Prozesses. Diese Ziele werden dann durch den PL-Mgr umgesetzt. Deutlich wird seine Funktion u. a. dadurch, dass er PLAs unterschreiben darf.

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6

Rollenbezeichnung

Rollenbeschreibung

Fachvorgesetzer Serviceconsumer (FV SC)

Der Fachvorgesetze auf Seiten des Serviceconsumers (FV SC) verantwortet den PLA auf Kundenseite. Er unterzeichnet das zwischen der Kundenrolle und dem PL-Manager ausgehandelte PLA.

IT-Betriebsverantwortlicher (ITBV)

Die IT-Betriebsverantwortlicher bezeichnet als übergeordnete Rolle alle Funktionen und Rollen, die zum Betrieb eines Services notwendig sind. Hierunter fallen z. B. Rollen im Umfeld des Serverbetriebs, der Netzinfrastruktur oder der Nutzerverwaltung.

Tabelle 9: Rollen im Protection Level Management Es ist vorstellbar, die Rollen Kunde und Fachvorgesetzter Serviceconsumer auf der einen, sowie Protection Level Manager und Fachvorgesetzter Serviceprovider auf der anderen Seite zusammenzufassen.

6.4

Aufbau der Prozessbeschreibung

Ein Prozess – in diesem Fall das Protection Level Management – unterteilt sich in Verfahren, welche wiederum aus einzelnen Aktivitäten bestehen. Jedes Verfahren des PLM-Prozesses wird in zwei Bereichen dargestellt. Nach einer kurzen Übersicht folgt eine detaillierte AktivitätenAufstellung der Verfahren. Die Übersicht eines Verfahrens erfolgt tabellarisch in folgender Form: - Input/Startereignis: Jedes Verfahren wird durch ein Startereignis (Input) ausgelöst. Dieses

Ereignis wird hier benannt. - Verfahrensziele: Durch die Aktivitäten eines Verfahrens werden bestimmte Ziele verfolgt, die

an dieser Stelle beschrieben werden. - Output/Ergebnis: Jedes Verfahren schließt mit einem Ergebnis (Output) ab. Ein solches

Ergebnis kann auch wieder Startereignis für ein nachgelagertes Verfahren sein. Die Darstellung der Aktivitäten in den einzelnen Verfahren erfolgt tabellarisch in folgender Form: - Aktivität: In dieser Spalte werden die innerhalb des Verfahren durchführbaren bzw.

durchzuführenden Aktivitäten aufgeführt. Die Übersicht zeigt innerhalb dieser Studie lediglich eine Auswahl möglicher Aktivitäten, die innerhalb einer konkreten Situation einer Behörde oder Einrichtung ergänzt und konkretisiert werden müsste. - Beschreibung: Neben der Nennung der Aktivität wird hier kurz beschrieben, wie diese Aktivität

auszuführen ist. - Hilfsmittel: Hilfsmittel können z. B.: Software-Tools oder Dokumentenvorlagen sein, die die

ausführende Rolle bei der Durchführung der Aktivität unterstützt. - Rollen: Innerhalb einer Rolle werden thematische Aktivitäten gebündelt und einem

Rolleninhaber zugeordnet. In der Tabelle wird jeweils angegeben, welche Verantwortlichkeit

Bundesamt für Sicherheit in der Informationstechnik

69

6 Protection Level Management – PLM

eine Rolle für eine bestimmte Aktivität besitzt. Hierbei wird die sogenannte RACI-Zuodnung verwendet: - R (responsible) steht für die Durchführungsverantwortung, d. h. für die eigentliche

Durchführung der Aktivität. - A (accountable) steht für die Ergebnisverantwortung, d. h. die Person die Verantwortung

aus juristischer oder organisatorischer Sicht trägt - C (consulted) steht für eine beratende Verantwortung, d. h. die Rolle wirkt bei der

entsprechenden Aktivität beratend mit, ohne die Aktivität an sich durchzuführen. - I (informed) beinhaltet das Informationsrecht einer Rolle, d. h. eine Person, die über die

Aktivität oder dessen Ergebnis informiert wird oder das Recht hat, informiert zu werden.

6.5

Verfahren im PLM

6.5.1 Ermittlung von Schutzanforderungen Input/Startereignis Bedarf an Vereinbarung von Sicherheitsgarantien in einem PLA

Verfahrensziele

Output/Ergebnis

Ziel des Verfahrens Schutzanforderungen (Ermittlung von Anforderungen an PLA) ist es, in einem iterativen Prozess zwischen Serviceconsumer und Serviceprovider ausgehend von den Schutzzielen die benötigten Sicherheitsgarantien und technischen Parameter zu vereinbaren.

Dokumentation der Serviceanforderungen in Form von Schutzzielen und Sicherheitsgarantien als Vorstufe zu einem PLA Beiderseitige Kenntnis der Anforderungen

Tabelle 10: Verfahrensübersicht Ermittlung von Anforderungen an PLA

70

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6

FV SC

IT-BV

FV SP

IT-Sibe SC

Rollen IT-Sibe SP

Hilfsmittel Kunde

Beschreibung

PL-Mgr

Aktivität

A

C

A

A

C

C

A

A

C

I

A

A

C

Schutzziele definieren

Der notwendige Schutzbedarf und die konkreten Schutzziele werden (aus Kundensicht) definiert.

Template PLAAnforderungen Servicekatalog Bestehende Schutzbedarsfe ststellung

R

C

Sicherheitsanforderungen erheben

Im Rahmen der Anforderungsaufnahme wird die aus dem Schutzbedarf resultierende Definition der Schutzziele und der Sicherheitsanforderungen abgestimmt.

Template R PLAAnforderungen Servicekatalog Gesprächsprotokoll

R

C

C

Notwendige Sicherheitsgarantien ermitteln

Wie in Kapitel 4.5.2 Sicherheitsgarantien beschrieben, werden notwendige organisatorische und technische Sicherheitsmerkmale abgestimmt und entsprechende qualitative und quantitative Metriken zur Messung des vereinbarten Niveaus abgestimmt.

Template R PLAAnforderungen Servicekatalog Gesprächsprotokoll Grundschutzkataloge

R

C

Messung/Prüfung Jede in einem PLA zu vereinbader Anforderun- renden Schutzanforderung sollte gen vereinbaren möglichst objektiv messbar sein. Schon bei Aufnahme der Anforderungen an ein PLA sollte festgelegt werden, welcher Maßstab und welche Prüfer später von beiden Parteien akzeptiert werden. Als Instrumente für die nicht direkt messbaren Parameter stehen zur Verfügung:

Servicekatalog R Template PLA-Anforderungen

R

C

1. Standardisierte Zertifikate (überprüft durch Dritte) 2. Regelmäßige Sicherheits-Audits 3. Verdachtsfallüberprüfungen

Bundesamt für Sicherheit in der Informationstechnik

71

Beschreibung

IT-Sibe SP

IT-Sibe SC

FV SP

FV SC

IT-BV

Hilfsmittel

Rollen

Voraussetzungen für die Servicelieferung vermitteln

In der Praxis ist der Bezug der meisten IT-Services und die Lieferung der Servicequalitäten an bestimmte Voraussetzungen gebunden. So wird in der Bundesverwaltung in aller Regel der Anschluss an die „Netze des Bundes“ Voraussetzung sein. Diese Voraussetzungen sollen an dieser Stelle mit dem Kunden abgestimmt werden.

Servicekatalog R Template PLAAnforderungen

R

C

C

A

A

C

Anforderungen mit Möglichkeiten abgleichen

Dieser Schritt ist als Start in ei- Servicekatalog R ner iterative Abfolge zu verste- Anforderungshen: Die mit dem Kunden bisher Entwürfe erhobenen Schutzanforderungen – ggf. unter Hinzuziehung des Sicherheitsbeauftragten – werden in der IT auf Machbarkeit geprüft. Eventuell werden hier Alternativen vorgeschlagen, die wiederum mit dem Kunden abgestimmt werden. Die Iteration läuft so lange, bis sich Kunde und Dienstleister auf ein Set von Anforderungen und Möglichkeiten geeignet, so dass im nachfolgenden Verfahren PLAs und absichernde Vereinbarungen erstellt werden können.

R

C

C

A

A

C

PL-Mgr

Aktivität

Kunde

6 Protection Level Management – PLM

Tabelle 11: Verfahrensbeschreibung Ermittlung von Anforderungen an PLA

72

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6

6.5.2 Vereinbarung von PLAs und Absicherung Input/Startereignis Dokumentierte Sicherheitsanforderungen/ Serviceanforderungen als Vorstufe zu einem PLA

Verfahrensziele

Output/Ergebnis

Ziel des Verfahrens ist die Abgeschlossene PLAs und Formulierung und absichernde Vereinbarungen „Unterzeichnung“ des PLAs sowie die Formulierung und Aushandlung von absichernden Vereinbarungen.

Tabelle 12: Verfahrensübersicht Vereinbarung von PLAs und Absicherung

IT-BV

FV SC

FV SP

IT-Sibe SC

Rollen IT-Sibe SP

Hilfsmittel Kunde

Beschreibung

PL-Mgr

Aktivität

Geforderte Die in den Schutzanforderun- PLA-Anforde- R Serviceleistung und gen formulierten und von rungen -qualitäten prüfen Kunden benötigen Sicherheits- Template PLA garantien werden in diesem Template AbSchritt hinsichtlich ihrer Umsichernde Versetzbarkeit verifiziert. Wurden einbarungen bei der Aushandlung der Verantwortung die Betriebsrefera- Prozessbete und Sicherheitsverantwortli- schreibung chen intensiv beteiligt, dürft dieser Schritt in der Regel keine Überraschungen bergen, so dass der Formulierung eines PLAs nichts im Wege stehen dürfte.

C

A

C

Umsetzung initialer Bei der Zusicherung von SiZertifizierungen cherheitsgarantien über Zertprüfen ifikate können hohe initiale Aufwände entstehen, wenn große Zertifizierungen wie z.B. ISO27001 noch durchgeführt werden müssen. Der PL-Mgr prüft gemeinsam mit dem IT-Betrieb den Aufwand für die Umsetzung der notwendigen Maßnahmen, die benötigten Ressourcen und legt Termine fest.

C

A

R

Bundesamt für Sicherheit in der Informationstechnik

PLA-Anforde- R rungen Template PLA Template Absichernde Vereinbarungen Prozessbeschrebung Externe Beratung durch Auditor

73

6 Protection Level Management – PLM

PLA-Entwurf erstellen

Der PL-Mgr erstellt nun eine erste Version des PLA. Diesen verwendet er zur näheren Abstimmung mit den eigentlichen Leistungserbringern – d. h. in der Regel den Betriebsreferaten

PLAR Anforderungen Template PLA Prozessbeschreibung

Serviceleistung und Die im PLA-Entwurf auf -qualitäten Basis der aufgenommen absichern Anforderungen formulierten Serviceleistungen und -qualitäten werden mit den ITReferaten und ggf. externen Leistungserbringern abgestimmt und über entsprechende Vereinbarungen abgesichert. Spätestens jetzt sollten abgestimmte Terminzusagen für die Umsetzung initialer Zertifizierungen vorliegen.

Template Ab- R sichernde Vereinbarungen PLA-Entwurf

PLA Entwurf mit abstimmen

Der abgesicherte PLAEntwurf kann nun dem Kunden vorgestellt und mit diesem abgestimmt werden. Aufgrund der engen Zusammenarbeit bei Erhebung der Anforderungen sollte auch dieser Schritt lediglich „formellen Charakter“ haben.

PLA-Entwurf R Dokumentierte PLA-Anforderungen

PLA „unterzeichnen“

Das PLA kann nun unterzeichnet werden. In aller Regel werden dies die Fachvorgesetzen durchführen. Da innerhalb der Bundesverwaltung PLAs keine rechtliche Wirkung entfalten, lassen sich hier aber auch andere Regelungen treffen – z. B. auch der Verzicht auf eine Unterschrift.

PLA-Entwurf Prozessbeschreibung Rollenbeschreibung

74

IT-BV

FV SC

FV SP

IT-Sibe SC

Rollen IT-Sibe SP

Hilfsmittel Kunde

Beschreibung

PL-Mgr

Aktivität

A

IC

R

IC IC I

A

IC

I

R

I

A R

A R

I

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6 Tabelle 13: Verfahrensbeschreibung Vereinbarung von PLAs und Absicherung

6.5.3 Überwachung von PLAs Input/Startereignis Abgeschlossene PLAs und absichernde Vereinbarungen

Verfahrensziele

Output/Ergebnis

Ziel des Verfahrens ist die Berichte zur Service- und Einrichtung und Durchführung Leistungsqualität von Messungen bezüglich der vereinbarten Serviceleistungen und -qualitäten sowie die Umsetzung des Berichtswesens

Tabelle 14: Verfahrensübersicht Überwachung von PLA

Bundesamt für Sicherheit in der Informationstechnik

75

6 Protection Level Management – PLM

I

A I

R

Überwachung und Die eingerichteten Reports Reporting- und I Reports einrichten und Monitoringverfahren müs- Monitoringund „live schalten“ sen ihre Arbeit spätestens zum Tools Beginn der Servicelieferung aufnehmen.

I

I

I

A I

R

Initiale Zertifizierungen umsetzen

Bis zum Zeitpunkt der Externe Serviceaufnahme müssen die Auditoren vereinbarten Zertifizierungen vorliegen. Geht der Scope der Zertifizierung wie bei ISO 27001 auf Basis IT-Grundschutz über den eigentlichen Service hinaus (übergreifende Bausteine), sollte die Verantwortung zentral liegen.

I

A R

I

R

R

PLA-Reporting

Nach Live-Schaltung der

Die im PLA und den absichernden Vereinbarungen zugesagten Messungen und Reports müssen eingerichtet werden. Je nach Methode ist dies nicht trivial.

PLA R Absichernde Vereinbarunge n Reporting und Monitoring1. Für vereinbarte direkt messba- Tools re Parameter müssen die zuge- Template sagten Messungen und Servicereports

IT-BV

I

PLA-Messungen einrichten

FV SC

I

PL-Mgr

FV SP

Rollen IT-Sibe SC

Hilfsmittel

IT-Sibe SP

Beschreibung

Kunde

Aktivität

Reports eingerichtet werden.

2. Zertifizierungen müssen ihren Bedingungen entsprechend aktuell gehalten werden. Dies geschieht in der Regel durch Audits Dritter. 3. Auch muss der Kunde oder ein Dritter – wie in Kapitel 5.9 Abschnitt 5: AuditBerechtigungen beschrieben – in der Lage sein, die Messungen selber durchzuführen, bzw. diese zu verifizieren.

76

R A

Reporting- und I

I

A

I

R

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6

IT-BV

C

R, R, I A A

I

R

Verdachtsfallüberprüfungen vornehmen

Vor allem nach Störungen Reporting- und C (Incidents) bei denen z. B. MonitoringShortcomings aufgetreten Tools sind, besteht der Kundenwunsch nach schneller und unabhängiger Überprüfung. Dazu sollte im PLA bereits ein Verfahren zur Überprüfung dieser Vorfälle vereinbart worden sein, welches hier durchgeführt wird. Oft wird diese Zusage mittels eines bestimmten Kontingents an Audit-Tagen vereinbart, um die dafür benötigten Ressourcen planbar zu machen.

C

A

I

R

Reports erstellen

Die über eine Periode gesammelten Daten aus dem Qualitätsmonitoring und dem Incident Management müssen in Berichten so aufbereitet werden, dass der entsprechen-

durchführen

IT-Sibe SC

PLA R Reporting- und MonitoringTools

PL-Mgr

FV SC

Rollen FV SP

Hilfsmittel

IT-Sibe SP

Beschreibung

Kunde

Aktivität

Messverfahren werden die Monitoringvereinbarte Qualitätsparameter Tools fortlaufend gemessen

Audits durchführen Analog der in den PLAs vereinbarten Messverfahren muss in regelmäßigen Sicherheits-Audits geprüft werden, in welchem Sicherheitsrisiken erhoben und analysiert sowie Schwachstellen innerhalb des IT-Services aufgezeigt werden. Für vom Kunden gewünschte Stichprobenaudits sollte eine Begleitung und Unterstützung durch den PL-Mgr eingeplant werden.

Bundesamt für Sicherheit in der Informationstechnik

PLA R Berichte Monitoringergebnisse

A

I

A

77

6 Protection Level Management – PLM

I

I

I

A I

IT-BV

FV SP

R

FV SC

IT-Sibe SC

Rollen IT-Sibe SP

Hilfsmittel Kunde

Beschreibung

PL-Mgr

Aktivität

de Empfänger diese lesen und bewerten kann. Während auf die absichernden Vereinbarungen bezogene Reports eher technischen Charakter behalten können, müssen Berichte an den Kunden in der Regel „übersetzt“ und aufbereitet werden. Form und Berichtszyklus ist hierbei mit dem Kunden abzustimmen (in PLA enthalten). Reports versenden

Die erstellten Berichte werden E-Mail regelmäßig an die Empfänger, Reports d. h. den Kunden, die internen Betriebsreferate und ggf. die IT-Sicherheitsbeauftragten versendet.

I

Tabelle 15: Verfahrensbeschreibung Überwachung von PLA

6.5.4 Aktualisierung/Überarbeitung von PLAs Input/Startereignis Berichte zur Service- und Leistungsqualität

Verfahrensziele

Output/Ergebnis

Ziel des Verfahrens Aktualisierung/Überarbeitung von PLAs ist die Auswertung der Qualitätsreports und die ständige Verbesserung von Service- und Leistungsqualität und inkl. deren Vereinbarung in PLAs und absichernden Abmachungen

Überarbeitete PLAs und absichernde Vereinbarungen Ständige Verbesserung des ITService

Tabelle 16: Verfahrensübersicht Aktualisierung/Überarbeitung von PLAs

78

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6

Serviceberichte prüfen

Incident Reviews

Service Review Meeting durchführen

Der PL-Mgr überprüft regelmäßige sämtliche Reports und gleicht diese mit den vereinbarten Leistungen haben. Ziel ist es, möglichst genau die vereinbarten Qualitäten zu treffen. Hierbei gilt es auch Trends zu erkennen und rechtzeitig auf diese zu reagieren.

Service Reports

Neben den Serviceberichten sollten in diesem Verfahrens auch vergangene Störungen (Incidents) auf Sicherheitsrelevanz geprüft und entsprechende Verbesserungsmaßnahmen zur Vermeidung künftiger Security-Incidents getroffen werden.

Service Reports

Auf Basis der Auswertung der Berichte plant und initiert der PLMgr. mit Kunden sowie intern mit den Betriebsverantwortlichen regelmäßige Service Review Meetings. Neben der Kontaktpflege (siehe auch nachstehende Verfahrensbeschreibung) wird in den Serview Review Meetings ein Rückblick auf die in der Vergangenheit wahrgenommene Servicequalität gerichtet. Hierbei gilt es Verbesserungspotenziale zu erkennen, die u. a. der Sicherstellung der Zufriedenheit des Kunden dienen sollen. Des weiteren wird in den Meetings auch ein Ausblick auf sich absehbar ändernde Kundenanforderungen abgestimmt, damit der IT-Dienst-

Service Reports

Bundesamt für Sicherheit in der Informationstechnik

IT-BV

FV SC

FV SP

IT-Sibe SC

Rollen IT-Sibe SP

Hilfsmittel Kunde

Beschreibung

PL-Mgr

Aktivität

R

I

A

I

R

C

A

R, C

PLA Absichernde Vereinbarungen

IncidentTracking Tool (User Help Desk/TicketTool) R

R

CI CI A

A

R

PLA Absichernde Vereinbarungen MeetingProtokoll

79

6 Protection Level Management – PLM

FV SC

IT-BV

R

R

CI CI A

A

CI

R

R

CI CI A

A

R

R

R

CI CI A

A

R

IT-Sibe SC

FV SP

Rollen IT-Sibe SP

Hilfsmittel Kunde

Beschreibung

PL-Mgr

Aktivität

leister rechtzeitig reagieren kann. Service Reports erläutern

Änderungsnotwendigkeiten prüfen

Änderungsmöglichkeiten prüfen

80

Serviceberichte sollen keine technischen Kennzahlentabellen sein, sondern möglichst aus Sicht des Kunden erstellt sein. Trotzdem muss sichergestellt werden, dass die Reports von den Empfängern auch verstanden werden. Der PL-Mgr. sollte die Reports – zumindest in der Anfangsphase der Servicelieferung – erläutern und bei Bedarf anpassen.

Service Reports

Auf Basis der Service Berichte, des Service Review Meetings und ggf. weitere Rückmeldungen von Kunden wird nun geprüft, ob Änderungen an PLA und entsprechenden unterstützenden Vereinbarungen notwendig sind. Hierbei ist zu beachten, dass dies nicht nur der Fall ist, wenn ein IT-Service in einer schlechteren Servicequalität geliefert wurde, sondern auch im umgekehrten Fall – wenn „zu viel“ geliefert wurde.

Service Reports

Neben der Änderungsnotwendigkeit ist auch die Änderungsmöglichkeit an PLA kontinuierlich zu prüfen. Dies ist z. B. bei technischen Fortschritten oder Technologiewechseln regelmäßig der Fall, aber auch bei sich geändert habenden Anforderungen der Kunden oder organisatorischen

Kundenrückmeldungen

PLA Absichernde Vereinbarungen

PLA Absichernde Vereinbarungen Protokoll Service Review Meeting

Bereichte der IT-BV und ITSibe

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6

IT-BV

R

CI CI CI I A

I

R

SIP

R

I

I

R

SIP

R

IT-Sibe SC

FV SC

FV SP

Rollen IT-Sibe SP

Hilfsmittel Kunde

Beschreibung

PL-Mgr

Aktivität

Änderungen (z. B. Netzzugänge, Standorte) Serviceverbesserung initiieren

Alle erkannten Änderungsund Verbesserungsmöglichkeiten und -notwendigkeiten sollten an zentraler Stelle aufgenommen und entsprechende Maßnahmen hierfür geplant werden. Dies geschieht in einem „Service Improvement Plan“, den der PL-Mgr. gemeinsam mit Kunden und ITBV erstellt und abstimmt.

Service Reports

Serviceverbesserung umsetzen

Die im SIP formulierten Verbesserungsmöglichkeiten sollen nun wie vereinbart umgesetzt werden.

Neuen PLA Entwurf erstellen

Sofern sich mit den Verbesserungsmaßnahmen Änderungen am Leistungs- und Qualitätsinhalt ergeben, erstellt der PLMgr. erneut einen PLA Entwurf, sichert und stimmt diesen ab. Auch dieser neue PLA wir dann wieder unterzeichnet (siehe Verfahren6.5.2 Vereinbarung von PLAs und Absicherung)

SIP Service Improvement Plan

CI I

A

CI I

A

I

PLA-Entwurf PLA Absichernde Vereinbarungen Servicekatalog

Tabelle 17: Verfahrensbeschreibung Aktualisierung/Überarbeitung von PLAs

Bundesamt für Sicherheit in der Informationstechnik

81

6 Protection Level Management – PLM

6.5.5 Kontaktpflege Input/Startereignis Alle Aktivitäten mit Kundenbezug der vorherigen Verfahren

Verfahrensziele Ziel des Verfahrens Kontaktpflege ist kontinuierliche Pflege der Beziehung zwischen dem Kunden und dem Serviceprovider zur Sicherstellung der Kundenzufriedenheit.

Output/Ergebnis Kundenzufriedenheit

Tabelle 18: Verfahrensübersicht Kontaktpflege

Kundenzufrie- R denheitsumfrage

R

A

I

I

I

C

IT-Sibe SC

IT-BV

Der PL-Mgr. sollte die Kundenzufriedenheit kennen. Diese kann in regelmäßigen Abstimmen formalisiert erhoben werden oder z. B. in den Service Review Meetings erfahren werden.

FV SC

Kundenzufriedenheit messen

FV SP

Rollen IT-Sibe SP

Hilfsmittel Kunde

Beschreibung

PL-Mgr

Aktivität

Service Review Meetings

Verbesserungsmaßnahmen zur Kundenzufriedenheit planen

Auf Basis der erkannten Kun- SIP denzufriedenheit gilt es bei Bedarf entsprechende Verbesserungsmaßnahmen zu initiieren. Dies kann z. B. auch mit Hilfe des beschriebenen Service Improvement Plans erfolgen.

R

I

A

Kontinuierliche Kommunikation mit Kunden sicherstellen

Auch ohne konkreten Anlass wie z. B. die Service Review Meetings oder die Übergabe von Service Reports soll die Kommunikation mit Kunden regelmäßig erfolgen und sicher gestellt werden. Dies hilft z. B. Anforderungen frühzeitig zu erkennen oder Anpassungsbedarf an den Servicequalitäten zeitig zu planen.

R

R

A

82

Bundesamt für Sicherheit in der Informationstechnik

Protection Level Management – PLM 6

Beschwerdemeldung Protokoll Service Review Meeting

A

IT-BV

FV SC

IC

FV SP

R

IT-Sibe SC

Es sollte selbstverständlich sein, dass Kundenbeschwerden aufgenommen und möglichst zur Zufriedenheit der Kunden bearbeitet werden. Aber auch ein Lob von Kunden stellt einen wichtigen Indikator für die Serviceplanung dar. Auf diese Weise kann z. B. erkannt werden, welche Serviceelemente Kunden besonders wichtig sind und daher mit besonderer Sorgfalt bereitgestellt werden sollten.

Rollen IT-Sibe SP

Beschwerden/Lob bearbeiten

Hilfsmittel Kunde

Beschreibung

PL-Mgr

Aktivität

RI

Tabelle 19: Verfahrensbeschreibung Kontaktpflege

6.6

Integration in die Aufbauorganisation

Einige Fragen, die in nahezu allen Vorhaben des Prozess- und IT-Servicemanagement regelmäßig beantwortet werden müssen, betreffen die Integration der entwickelten Prozesse und Rollenbeschreibungen in die Aufbauorganisation. So muss hierbei zum Beispiel regelmäßig geklärt werden, wie Rollen möglichst optimal besetzt werden können, bzw. wo Rolleninhaber „organisatorisch angesiedelt“ sein müssten. Es folgen häufig weitere Gedanken hinsichtlich Reorganisation, Bildung von Matrixorganisationen oder Stabsstellen. Hier muss jedoch festgestellt werden, dass diese Fragen immer nur im konkreten Organisationszusammenhang beantwortet werden können. An dieser Stelle soll daher lediglich ein Hinweis zur Antwort in dieser Fragestellung gegeben werden: Grundsätzlich sollte beachtet werden, dass die Rollenbesetzung in einem PLM-/SLM-Vorhaben weniger an der aufbauorganisatorischen Zuordnung festzumachen ist. Verdeutlicht werden kann dies an der Rolle des PL-Managers: Seinen Aufgaben folgend, wird von einem PL-Manager verlangt, als Schnittstelle zwischen der Kundenorganisation und der eigenen IT-Organisation zu fungieren. Er ist gewissermaßen Dolmetscher zwischen diesen Parteien: Er soll die Kundensprache in IT-Spezifikationen übersetzen und umgekehrt. Hierfür benötigt der PL-Manager möglichst gute IT-Kenntnisse und zugleich elementare Kenntnisse der Anforderungen des Kunden. Des Weiteren wird vom PL-Manager ein gewisses Verhandlungsgeschick und Belastungsvermögen verlangt, wenn es gilt, widerstreitende Interessen zu harmonisieren sowie ein umfassenden Wissen in Fragen der IT-Sicherheit Sieht man sich vor dem Hintergrund eines solchen Anforderungsprofils in der eigenen Organisation um, wird man in aller Regel feststellen, dass nur wenige Personen geeignet sein werden, diese Bundesamt für Sicherheit in der Informationstechnik

83

6 Protection Level Management – PLM

Anforderungen zu erfüllen. Häufig wird dabei beobachtet, dass diese Personen auch in anderen Situationen wichtige Aufgaben übernommen haben (z. B. in Projekten), als Leistungsträger der Organisation gelten und als „unersetzbar“ gelten. Statt diese Personen nun aus ihren Organisationseinheiten – in denen sie ja gebraucht werden – zu lösen und im Zuge der Integration eines PLM-/SLM-Prozesses in eine andere Organisationseinheit umzusetzen, sollte zuvorderst geprüft werden, ob der Rolleninhaber seine neue Rolle als PLManager nicht auch aus seiner angestammten Organisationseinheit heraus erfüllen kann. Sofern hier z. B. Eskalationswege oder Schnittstellen aus der IT heraus (Haushalt/Organisation etc.) geklärt sind, sollte eine Umsetzung nicht unbedingt notwendig sein.

84

Bundesamt für Sicherheit in der Informationstechnik

Automatisierte Verarbeitung von PLAs im SOA-Umfeld 7

7

Automatisierte Verarbeitung von PLAs im SOAUmfeld

Im folgenden Kapitel soll ein vertiefender Blick auf einen besonderen Anwendungsfall für PLAs geworfen werden: Serviceorientierte Architekturen (SOA) umfassen dynamische Konzepte, nach denen für einen bestimmten Bedarf eines Kunden (Consumer) ein geeigneter Dienst (Service) eines Anbieters (Providers) erst zur Laufzeit durch eine zentrale Instanz (Broker) identifiziert und ausgewählt und dabei ggf. mit anderen Diensten zur Bearbeitung einer komplexeren Fachausgabe kombiniert wird („Orchestrierung“) wird. Dieses Konzept der „späten Bindung“ kann auch domänenübergreifend realisiert werden. Dabei umfasst die SOA Dienste verschiedener Anbieter bzw. Domänen und sammelt die Dienstbeschreibungen in einem Servicekatalog. Ein Consumer kann dann über den Servicekatalog eines Providers direkt oder mit Hilfe eines Brokers indirekt zwischen den in Frage kommenden Diensten wählen. In diesem Szenario sind die Partner der Kunden-Dienstleister-Beziehung also nicht von vornherein festgelegt, sondern werden erst zur Laufzeit der konkreten Anfrage festgelegt. Hierfür werden Lösungen benötigt, um auch die Sicherheitsanforderungen des Kunden in die Diensteauswahl einzubeziehen und eine Zusicherung des Dienstbetreibers zum umgesetzten Sicherheitsniveau zu erhalten, mit anderen Worten: Die Vereinbarung von Sicherheitsgarantien muss automatisiert erfolgen, wenn man das SOA-Konzept in dieser Form nutzbar machen möchte. Die folgenden Abschnitte untersuchen die Machbarkeit einer solchen automatisierten Vereinbarung von Sicherheit mit Hilfe von PLAs und zeigen Lösungsansätze und Grenzen in diesem Bereich auf. Dazu werden zunächst die hier relevanten Kernaspekte von serviceorientierten Architekturen zusammengefasst, dann werden vorhandene Lösungsansätze untersucht und verbleibende Handlungsbedarfe identifiziert.

7.1

Serviceorientierte Architekturen (SOA)

In diesem Kapitel werden die für diese Studie relevanten Grundeigenschaften von serviceorientierten Architekturen kurz vorgestellt. Eine vollständige Diskussion der Eigenschaften und Besonderheiten kann und soll an dieser Stelle nicht erfolgen; tiefergehende Informationen zu den sicherheitsrelevanten Architektureigenschaften hierzu finden sich im SOA-Sicherheitskompendium des BSI [BSI-SOA 2009]. SOA ist ein technologieunabhängiges, plattformübergreifendes Architekturkonzept, welches zur losen Kopplung von IT-Komponenten zu einem komplexen Service eingesetzt wird. Auch wenn eine allgemein akzeptierte, einheitliche Definition des Begriffs „Serviceorientierte Architektur“ nicht vorliegt, besteht doch weitgehende Einigkeit über die charakteristischen Eigenschaften einer SOA: - Jeder Dienst wird über eine dokumentierte Schnittstelle aufgerufen und ist mit einer

standardisierten Beschreibung in einem zentralen Servicekatalog hinterlegt. - Durch die lose Kopplung der einzelnen Dienste besteht eine möglichst geringe Abhängigkeit der

einzelnen Dienste untereinander, die vollständig über die dokumentierten Schnittstellen abgebildet wird. Dadurch sind die einzelnen Dienste austauschbar.

Bundesamt für Sicherheit in der Informationstechnik

85

7 Automatisierte Verarbeitung von PLAs im SOA-Umfeld

- Die Funktion eines Dienstes und seine Beschreibung sind unabhängig von den Details der

Implementierung, insbesondere auch der verwendeten Programmiersprache und Plattform. - Durch die oben aufgeführten Eigenschaften erreichen die Dienste ein möglichst hohes Maß an

Wiederverwendbarkeit. - Der Dienst selbst ist zustandslos, d. h. jede Anfrage bildet einen in sich abgeschlossenen

Vorgang. Damit soll erreicht werden, dass die in der SOA realisierten Dienste ein größtmögliches Maß an Flexibilität im Einsatz, Standardisierung und dadurch Wiederverwendbarkeit erhalten. Für die vorliegende Betrachtung besonders relevant ist die Orchestrierung von Diensten, d. h. das Zusammensetzen von elementaren Diensten zu komplexeren Aufgaben. Diese kann entweder bereits bei der Entwicklung der Dienste als statische Bindung vorgesehen werden, wie dies z. B. unter dem Stichwort Enterprise Application Integration (EAI) durchgeführt wird. Es besteht aber auch die Möglichkeit, Dienste erst zur Laufzeit, d. h. wenn eine konkrete Anfrage zur Bearbeitung einer bestimmten Aufgabenstellung vorliegt, zu orchestrieren. Bei dieser „späten Bindung“ kommt typischerweise eine zentrale Service-Broker-Instanz zum Einsatz, wie die folgende Abbildung verdeutlicht:

Abbildung 10: „Späte Bindung“ von Diensten in der SOA

Die einzelnen Dienste werden dabei zunächst bei der Brokerinstanz in einer standardisierten Beschreibungssprache (Web Services Description Language – WSDL) registriert und dazu formalisiert beschrieben. Im Rahmen der Bearbeitung einzelner Anfragen kann der Broker dann aus den bei ihm registrierten Diensten geeignete Services auswählen und zur Bearbeitung der fachlichen Aufgabestellung kombinieren. Das folgende Beispiel soll den Ablauf veranschaulichen: Die Grundbuchämter einer Großstadt stellen Dienste in einer von der Stadtverwaltung betriebenen SOA bereit. Wir betrachten jetzt den Anwendungsfall eines Notars, der einen beweissicheren Grundbuchauszug benötigt und dazu den Service-Broker anfragt. Der Service-Broker ermittelt nun den passenden Dienst des für die Anfrage 86

Bundesamt für Sicherheit in der Informationstechnik

Automatisierte Verarbeitung von PLAs im SOA-Umfeld 7

zuständigen Grundbuchamtes. Zusätzlich soll die erteilte Auskunft zum Zwecke der Beweissicherheit mit einem Zeitstempel versehen werden. Hierzu ermittelt der Broker passende in der SOA angebotene Zeitstempeldienste privater Trustcenter und „orchestriert“ Grundbuchdienst und Zeitstempeldienst zur einem gemeinsamen höheren Service für die Erfüllung der Anfrage.

Abbildung 11: Dynamische Kunde-Dienstleister-Beziehungen in einer SOA (Beispiel)

In diesem Szenario entsteht also zur Laufzeit eine komplexe Vertragsbeziehung zwischen Notar, Stadtverwaltung, Grundbuchamt und Trustcenter. Dabei können auf allen beteiligten Seiten Sicherheitsanforderungen an die jeweils anderen Parteien entstehen („mehrseitige Sicherheit“, vgl. [Ecke2007]). Gleichzeitig ist davon auszugehen, dass möglicherweise unterschiedliche Sicherheitsniveaus realisiert sind, für die keine einheitliche Beschreibung vorliegt. Im nächsten Abschnitt werden daher zunächst vorhandene Konzepte zur Realisierung von Sicherheit in SOA betrachtet, um die Frage zu beantworten, ob sich damit die erforderlichen Sicherheitsbeziehungen zwischen den beteiligten Parteien vollständig abbilden lassen.

7.2

Sicherheitsstandards für Web Services

Zur Umsetzung von SOA sind verschiedene technologische Ansätze möglich; im Fokus der Diskussion stehen dabei heute SOA auf der Grundlage von Web Services, d. h. einzelnen Diensten, die XML-basierte Web-Schnittstellen anbieten und über eine standardisierte Beschreibungssprache

Bundesamt für Sicherheit in der Informationstechnik

87

7 Automatisierte Verarbeitung von PLAs im SOA-Umfeld

verwaltet werden können. Die Grundlage bildet dabei eine Reihe von Standards für Web Services („WS-*“) der Organization for the Advancement of Structured Information Standards (OASIS). Im Rahmen dieser Standardisierungsarbeit sind auch bereits einige Sicherheitsthemen aufgegriffen und behandelt worden, die im Folgenden vorgestellt werden. Dabei erfolgt an dieser Stelle keine tiefer gehende Erläuterung der Standards, sondern in erster Linie eine Bewertung ihres Beitrags für einen möglichen automatisierten Einsatz von PLAs in Verbindung mit SOA auf der Basis von Web Services.

7.2.1 WS-Security Standard

WS-Security

Zweck

Beschreibung des Einsatzes der Standards XML-Signature und XML-Encryption zur Absicherung der Vertraulichkeit, Integrität und Authentizität von SOAP-Nachrichten.

Bewertung

WS-Security regelt die Implementierung von Sicherheitsmechanismen in SOAP-Nachrichten. WS-Security stellt dabei keine Anforderungen an die Stärke der verwendeten Algorithmen oder an begleitende Sicherheitsmaßnahmen, z. B. für die Generierung kryptographischer Schlüssel. WS-Security macht somit selbst keine Aussage zum erreichten Sicherheitsniveau. Die standardisierte Anwendung von Sicherheitsmaßnahmen leistet dennoch einen relevanten Beitrag, weil damit zumindest für die von WS-Security definierten Sicherheitsmaßnahmen eine automatisierte Überprüfung erleichtert wird.

Tabelle 20: Verfügbare Standards: WS-Security

7.2.2 WS-SecureConversation Standard Zweck

88

WS-SecureConversation Die Absicherung von Nachrichten nach dem WS-SecurityStandard bringt beim Austausch vieler aufeinanderfolgender Nachrichten zwischen zwei Kommunikationspartner Ineffizienzen mit sich, weil die Verschlüsselung und Sicherung der Authentizität jeweils auf Nachrichtenebene erfolgt und damit für jede einzelne Nachricht vollständig vom Sender und Empfänger umgesetzt werden muss. Der Standard WS-SecureConversation schafft hier Abhilfe, indem er Mechanismen zur Aushandlung von über eine Folge von Nachrichten wiederverwendbaren Sitzungsschlüsseln beschreibt und damit eine effizientere Verarbeitung erlaubt. Bundesamt für Sicherheit in der Informationstechnik

Automatisierte Verarbeitung von PLAs im SOA-Umfeld 7

Standard Bewertung

WS-SecureConversation WS-SecureConversation stellt eine Erweiterung von WSSecurity dar, um bei größeren Mengen von ausgetauschten Nachrichten Effizienz und Sicherheit gemeinsam zu gewährleisten. Im Bezug auf die Vereinbarung von Sicherheit zwischen den Partnern gilt daher dasselbe wie bei WSSecurity (keine Abbildung eines konkreten Sicherheitsniveaus durch den Standard, aber Erleichterung der automatischen Prüfung durch standardisierte Implementierung).

Tabelle 21: Verfügbare Standards: WS-SecureConversation

7.2.3 WS-Trust Standard

WS-Trust

Zweck

Übergabe von Sicherheitskontexten mit Hilfe von SecurityToken – da die einzelnen Web Services zustandslos sind, muss der Security-Kontext (z. B. mit Informationen über den authentisierten Nutzer und das Authentisierungsniveau oder zugeordnete Rollen) jeweils beim Aufruf eines Services sicher übergeben werden. Die im Standard WS-Trust beschriebenen Security-Token bilden hierfür einen Mechanismus.

Bewertung

Der Standard beschreibt die Verwendung von Security-Token in Web Services und macht seinerseits wiederum keine Aussagen zum damit erreichten Sicherheitsniveau. Bezüge zur vorliegenden Problemstellungen sind damit nur am Rande gegeben.

Tabelle 22: Verfügbare Standards: WS-Trust

Bundesamt für Sicherheit in der Informationstechnik

89

7 Automatisierte Verarbeitung von PLAs im SOA-Umfeld

7.2.4 WS-Policy/WS-SecurityPolicy Standard

WS-Policy/WS-SecurityPolicy[WS-Pol2007]

Zweck

Beschreibung von Sicherheitsgarantien, um Zusicherungen über den Einsatz von Sicherheitsmechanismen nach den Standards WS-Security, WS-Trust und WSSecureConversation zu machen.

Bewertung

Der WS-SecurityPolicy-Standard bildet eine Anwendung des allgemeinen Standards WS-Policy auf Sicherheitsfunktionen und kommt dem Konzept eines automatisiert auswertbaren PLAs am nächsten. Allerdings umfasst er nur bestimmte, ausgewählte Sicherheitsparameter, die insbesondere die SOAKommunikation betreffen. Zahlreiche andere wichtige Sicherheitsparameter, wie z. B. das Patch-Management der Server, personelle Sicherheitsmaßnahmen bei der Systemadministration oder Maßnahmen zur Ausfallvorsorge werden von diesem Standard nicht erfasst. Über das Sicherheitsniveau insgesamt kann WS-SecurityPolicy deshalb keine Aussage machen.

Tabelle 23: Verfügbare Standards: WS-SecurityPolicy

7.2.5 WS-MetaDataExchange Standard

WS-MetaDataExchange

Zweck

Beschreibung von Mechanismen zum Austausch von Metadaten im Vorfeld des Aufrufs eines Services, z. B. zum Abruf von Security-Policies gemäß WS-SecurityPolicy.

Bewertung

Der Standard WS-MetaDataExchange regelt den Datenaustausch im Vorfeld der Service-Nutzung und ist daher relevant für die technische Implementierung einer möglichen PLA-Vereinbarung bei der „späten“ Bindung von Services. Er beschreibt jedoch lediglich Mechanismen zum Austausch und bleibt gegenüber den dabei ausgetauschten Inhalten neutral.

Tabelle 24: Verfügbare Standards: WS-MetaDataExchange

90

Bundesamt für Sicherheit in der Informationstechnik

Automatisierte Verarbeitung von PLAs im SOA-Umfeld 7

7.2.6 WS-Agreement Standard

WS-Agreement

Zweck

Beschreibung von Mechanismen zum Aushandeln von Vereinbarungen zwischen zwei Parteien, d. h. zur Spezifikation von Anforderungen und Beschreibung von Zusicherungen zur Erfüllung der Anforderungen.

Bewertung

WS-Agreement ist als Mechanismus zur Verhandlung von PLAs grundsätzlich geeignet, beschreibt jedoch nur abstrakt den Verhandlungsprozess, ohne Vorgaben zu den Inhalten der jeweiligen getroffenen Vereinbarung zu machen.

Tabelle 25: Verfügbare Standards: WS-Agreement

7.2.7 Bewertung Die vorhandenen Sicherheitsstandards für Web Services umfassen im Wesentlichen Implementierungsbeschreibungen für bestimmte Sicherheitsmechanismen (WS-Security, WS-Trust, WS-SecureConversation) sowie ein Rahmenwerk zur Beschreibung und zum Austausch von Sicherheitsanforderungen zu diesen Mechanismen (WS-Policy/WS-SecurityPolicy, WSMetaDataExchange, ggf. WS-Agreement). Die Zusammenhänge der einzelnen Standards werden in der folgenden Abbildung deutlich:

Abbildung 12: Relevante WS-Standards und ihre Beziehungen untereinander

Bundesamt für Sicherheit in der Informationstechnik

91

7 Automatisierte Verarbeitung von PLAs im SOA-Umfeld

Sie bilden damit einen formalen Rahmen für die Implementierung, Beschreibung und Vereinbarung dieser Sicherheitsmechanismen. Dabei ist jedoch zu beachten, dass die Betrachtung hier nur punktuelle technische Sicherheitsmechanismen umfasst, die sich insbesondere auf die Gestaltung der Schnittstelle des Dienstes beziehen (Verschlüsselung, Signatur, Authentisierung), und keinesfalls Aussagen über das Sicherheitsniveau eines Dienstes insgesamt erlaubt. Dieses Sicherheitsniveau wird bestimmt durch die Gesamtheit der vom Provider ergriffenen Maßnahmen – technische wie organisatorische und personelle. Für eine Aussage im Sinne eines PLAs greifen die den WS-Standards zugrunde liegenden Ansätze daher zu kurz. Dennoch sind hier Grundlagen gelegt, die auch für eine automatische PLA-Aushandlung Anwendung finden müssten: Es ist eine Policy-Sprache definiert (WS-Policy), in der Anforderungen unter Berücksichtigung von möglichen Alternativen formuliert und geprüft werden können. Es werden Architekturen für die Definition, Prüfung und Durchsetzung von Sicherheitspolicies diskutiert ([BSI-SOA 2009]). Es erscheint naheliegend, zur Lösung der Problemstellung den Standard WS-SecurityPolicy so zu erweitern, dass alle relevanten Sicherheitsmaßnahmen damit abgedeckt werden können. An dieser Stelle kommen jedoch die in Kap. 4 vorgestellten praktischen Einschränkungen zum Tragen: Die Gesamtheit der relevanten Sicherheitsmaßnahmen ist zu komplex, um sie im Rahmen eines PLAs vollständig aufzuführen, die Messbarkeit ist für viele Maßnahmen nur über Selbstauskünfte des Anbieters oder über eine Bestätigung durch Dritte (Zertifizierung) möglich, so dass eine automatisiertes Policy Enforcement an dieser Stelle nicht möglich ist.

7.3

Lösungsmöglichkeiten

In diesem Kapitel wird untersucht, inwieweit bestehende Ansätze für die Abbildung von ITSicherheit in SOA geeignet sind, um das mit PLAs verfolgte Ziel eines übergreifenden Sicherheitsmanagements in der Kunde-Dienstleister-Beziehung abzubilden. Schließlich wird auf dieser Grundlage ein eigener Vorschlag vorgestellt, mit dem sich das PLA-Konzept in komplexen SOA abbilden ließe.

7.3.1 SOA Security Framework Im SOA-Sicherheitskompendium des BSI [BSI-SOA 2009] werden im Kapitel 6 Ansätze für ein „SOA Security Framework“ vorgestellt. Dabei werden unterschiedliche Architekturansätze vorgestellt und miteinander verglichen: - Sicherheit als Infrastruktur, d. h. Sicherheit wird durch Adapter oder Proxys realisiert, die den

Diensten jeweils nach außen vorangestellt sind. - Sicherheit als Service, d. h. Sicherheitsfunktionen werden in eigenen Diensten gekapselt und von

dort zentral bereitgestellt.

92

Bundesamt für Sicherheit in der Informationstechnik

Automatisierte Verarbeitung von PLAs im SOA-Umfeld 7

- Sicherheit als Bestandteil der Applikationen, d. h. Sicherheitsfunktionen werden bei der

Implementierung der einzelnen Dienste jeweils mit berücksichtigt. Mit dem Ziel einer Trennung von Fachlogik und Sicherheit, insbesondere zum Zwecke der Wiederverwendbarkeit von Sicherheitsfunktionen, wird dabei von einer Implementierung der Sicherheit innerhalb der Dienste zugunsten der anderen beiden Varianten abgeraten. Dieser Argumentation ist zuzustimmen, so lange sich die Betrachtung auf bestimmte Sicherheitsfunktionen bezieht, bei denen eine Realisierung in den verschiedenen aufgeführten Varianten zur Disposition steht. Dabei darf nicht übersehen werden, dass dies nur einen begrenzten Ausschnitt eines Sicherheitsgesamtkonzeptes bilden kann, und durch eine Vielzahl von weiteren Sicherheitsmaßnahmen ergänzt werden muss, bei denen sich die oben aufgeführte Alternative nicht stellt. Personelle Sicherheitsmaßnahmen für die Administration der Systeme eines Web Service Providers lassen sich eben weder als Service noch als Infrastruktur kapseln, sondern müssen übergreifend organisatorisch umgesetzt werden. Gleiches gilt für das Patch-Management, den Umgang mit IT-Sicherheitsvorfällen, die Ausbildung des eingesetzten Personals und viele andere Bereiche mehr. Die Diskussion über die geeignete Architektur für ein SOA Security Framework darf daher nicht missverstanden werden in dem Sinne, dass durch die Kapselung von Sicherheit in Infrastrukturkomponenten oder Diensten eine Berücksichtigung von Sicherheit in der Realisierung der einzelnen Dienste oder bei ihrem Betrieb verzichtbar wird; es werden lediglich technische Einzelaspekte der IT-Sicherheit aufgegriffen und übergreifend gelöst. Die Realisierung eines SOA Security Frameworks stellt daher keinen Ersatz für die gesamtheitliche Sicherheitsbetrachtung, wie sie im PLA angestrebt wird, dar. Die Aufgabenstellung der Kommunikation von Sicherheitsanforderungen des Dienstnutzers und der Zusicherung der Erfüllung dieser Anforderungen durch den Diensteanbieter bleibt daher auch bestehen, wenn für die SOA ein einheitliches Security Framework umgesetzt wird. Die Einforderung und Zusicherung bestimmter Sicherheitsgarantien (nämlich in Bezug auf die vom Framework realisierten Sicherheitsfunktionen) wird jedoch in solchen Umgebungen erleichtert.

7.3.2 Vereinbarung von Sicherheit durch standardisierte Bausteine In Kapitel 4 war der Ansatz vorgestellt worden, im Rahmen einer PLA-Vereinbarung auf zertifizierbare Standards aufzusetzen, sofern diese Standards in der Beschreibungstiefe ausreichend detailliert sind, um ein bestimmtes Sicherheitsniveau abzubilden. Diese Anforderung wird heute übergreifend nur durch die BSI-IT-Grundschutzkataloge erfüllt – auf vergleichbarem Detaillierungsgrad bewegen sich sonst nur Regelungen für sehr spezielle Einsatzbereiche, wie z. B. Vorgaben für die Kreditkartenverarbeitung ([PCI-DSS 2009]). Die in den IT-Grundschutzkatalogen definierten Bausteine bilden dabei grundsätzlich eine gute Grundlage für die Referenzierung in PLAs, da sie die Komplexität von der Maßnahmenebene auf eine Bausteinebene reduzieren und damit einfacher beschreibbar werden. So könnte im PLA ein Satz von Bausteinen angegeben werden, der vom Dienstleister umzusetzen und ggf. durch ein Zertifikat nachzuweisen ist. Allerdings erfordert die IT-Grundschutzvorgehensweise bei erhöhten Sicherheitsanforderungen wiederum eine ergänzende Risikoanalyse und verlässt damit das standardisierte Maßnahmenbündel.

Bundesamt für Sicherheit in der Informationstechnik

93

7 Automatisierte Verarbeitung von PLAs im SOA-Umfeld

Auch ist davon auszugehen, dass die Dienste in einer SOA sich mit den vorhandenen ITGrundschutz-Bausteinen nicht adäquat modellieren lassen. Ausgehend von diesen Vorüberlegungen wird nun vorgeschlagen, in Analogie zum IT-Grundschutz für SOA Sicherheitsbausteine zu definieren, die SOA-relevante Sicherheitsmaßnahmen zur Erreichung eines definierten Standard-Sicherheitsniveaus zusammenfassen und damit im PLA referenzierbar machen. Das PLA kann dann aus Sicht des Service-Nutzers eine Reihe von ITGrundschutz-Bausteinen der Standard-Kataloge und ergänzenden SOA-Bausteinen (als „Add-Ons“ zum IT-Grundschutz) aufführen und jeweils mit einer Anforderung versehen, nach der die Umsetzung des jeweiligen Bausteins entweder durch den Anbieter zuzusichern oder aber durch ein Zertifikat nachzuweisen ist. Wird in der SOA ein übergreifendes SOA Security Framework realisiert, so kann dessen Nutzung durch den Dienst als ein entsprechendes Add-On einfließen. Die Add-Ons können dabei nicht nur Besonderheiten der SOA abdecken, die sich mit dem ITGrundschutz nicht modellieren lassen (z. B. das Nutzermanagement in der SOA), sie können auch Erweiterungen zu bestehenden Grundschutzbausteinen für ein erhöhtes Sicherheitsniveau bilden. So könnte beispielsweise der Grundschutzbaustein „Sicherheitsgateway“ durch ein Add-On erweitert werden, das den Betrieb einer Web Application Firewall zum Schutz der Web Services in der SOA beschreibt und damit ein erhöhtes Schutzniveau abdeckt. Auch der umgekehrte Weg einer Absenkung des Sicherheitsniveaus gegenüber dem ITGrundschutz wäre über ein solches Add-On möglich und sinnvoll: So könnte für bestimmte Dienste mit deutlich niedrigeren Sicherheitsanforderungen in einem Add-On ein Bündel von Grundschutzmaßnahmen beschrieben werden, auf dessen Umsetzung für diesen Dienst verzichtet wird. Dies kann z. B. sinnvoll sein, wenn ein Dienst wie die Auflösung von Postleitzahlen zu Städtenamen angeboten wird, der ausschließlich mit öffentlichen Daten arbeitet und daher auf bestimmte Maßnahmen zum Schutz der Vertraulichkeit verzichten kann. Der Kunden könnte dann z. B. wählen zwischen einem Dienst mit der Umsetzung eines definierten Katalogs von Grundschutzbausteinen und einem alternativen (ggf. kostengünstigeren) Dienst mit denselben zugeordneten Bausteinen und dem Add-On „reduzierte Vertraulichkeitsanforderungen“. Für diesen Ansatz wäre es erforderlich, die in den Bausteinen enthaltenen Maßnahmen nach den Grundwerten (Vertraulichkeit, Integrität, Verfügbarkeit) auszuwählen, die sie schützen. Eine solche Zuordnung ist in den Grundschutzkatalogen bisher nicht enthalten und müsste daher für die Auswahl von Maßnahmen für Add-Ons erst geschaffen werden. Alternativ wäre es auch möglich, eine Zuordnung der Gefährdungen zu den Grundwerten vorzunehmen und diese dann anhand der vorhandenen Kreuzreferenztabellen mittelbar über die Gefährdungen auf Maßnahmen abzubilden. Ein konkretes PLA könnte dann vorhandene Grundschutzbausteinen und zu definierende SOAAdd-Ons auswählen und zu einem insgesamt gewünschten Schutzniveau kombinieren, wie die folgende Grafik verdeutlicht:

94

Bundesamt für Sicherheit in der Informationstechnik

Automatisierte Verarbeitung von PLAs im SOA-Umfeld 7

Abbildung 13: Protection Level Agreements auf der Basis standardisierter Maßnahmenbündel (Bausteine)

Mit diesem Ansatz von IT-Grundschutzbausteinen und (SOA-)Add-Ons kann die Komplexität eines umfassenden Sicherheitskonzeptes auf die Anwendung von Bausteinen reduziert und damit im Rahmen eines PLA beschreibbar gemacht werden. Gleichzeitig wird es dadurch möglich, über die im PLA referenzierten Bausteine eine vergröberte, aber dennoch vollständige Beschreibung des erwarteten Sicherheitsniveaus zu leisten. Die Beschreibung erfolgt dabei hinreichend formal, um einen automatisierten Abgleich zwischen der Sicherheitsanforderungen (welche Bausteine müssen umgesetzt sein) und der Sicherheitszusage (welche Bausteine sind umgesetzt) zu realisieren und so z. B. bei der Vermittlung von Diensten durch eine Broker-Instanz zu berücksichtigen.

Bundesamt für Sicherheit in der Informationstechnik

95

8 Resümee und Ausblick

8

Resümee und Ausblick

Eine der zentralen Erkenntnisse dieser Studie ist, dass es bei der Definition von Protection-LevelAgreements im Gegensatz zur Definition von SLAs zum allergrößten Teil um eine fundamental andere Klasse von Parametern geht – Parameter, die nur einer indirekten Überprüfbarkeit unterliegen. Praktikabel abgebildet werden kann dies vor allem durch zertifizierbare Standards. Ein „Baukasten“ für solche Zertifikate existiert bisher nicht. Bestehende Standards wie die ITGrundschutzkataloge des BSI lassen kaum eine Differenzierbarkeit zu, wenn nur Teile umgesetzt werden sollen. Standards für bestimmte Anwendungsbereiche wie z. B. PCI-DSS existieren nur in sehr geringer Zahl. Im Ergebnis zeigen sich zwei unterschiedliche Ansätze für die Definition von PLAs, abhängig vom Automatisierungswunsch. Der erste Ansatz orientiert sich am klassischen SLA-Konzept und kann nicht automatisiert werden. Er kann verstanden werden als eine Erweiterung des SLAs mit dem zusätzlichen Qualitätsziel Sicherheit. Bei diesem Ansatz werden – als Grundlage – die Schutzziele aus Kundensicht spezifiziert und die eigentliche Auswahl und Umsetzung der Maßnahmen dem Dienstleister überlassen. Um abweichende Interpretation an bekannten oder kritischen Stellen zu vermeiden, wird dieser Ansatz durch explizit definierte Maßnahmen ergänzt. Dieser Ansatz entspricht im SLAKonzept der Vorgabe, den Dienst aus Kundensicht zu spezifizieren und überlässt die Auswahl der hinreichenden Maßnahmen der Stelle, die sie technisch am besten beurteilen kann. Dieser Ansatz benötigt als Mindestanforderung ein Sicherheitsmanagement auf Seiten des Dienstleisters, dass die Bewertung der Anforderungen, die Auswahl und Abwägung der Realisierungsalternativen sowie die letztendliche Festlegung und Umsetzung der angemessenen Maßnahmen entscheidet. Diese Aufgaben sind Management-Aufgaben und erfordern menschliche Mitwirkung; eine Automatisierung ist damit nicht möglich. Das Konzept eines reinen PLAs ohne SLA ist damit nur schwer sinnvoll zu verwirklichen. Bei der Definition nach dem ersten Modell, der Festlegung des Schutzniveaus, kann ohne eine Definition der Funktionalität kein Sicherheitsniveau festgelegt werden. Das Management der Vertragsbeziehung zeigt noch größere Parallelen zum Service-Level-Management auf. Insgesamt werden durch die Definition eines PLAs, spätestens bei der Definition der Verfügbarkeit, die meisten Punkte eines SLAs mit abgedeckt. In vielen SOA-Modellen wird Sicherheit von den einzelnen Services nach außen verlagert. Als Begründung dient, dass die Anforderungen sich erst für den zusammengesetzten Service ergeben, da sie aus dem modellierten Prozess kommen. Die bisherigen Ansätze beziehen sich vor allem auf die Schnittstellen der Services sowie auf spezielle Sicherheits-Services (Virenschutz, Verschlüsselung u. ä.). Außer Acht gelassen werden damit die Anforderungen, die sich für den Betrieb der Dienste als solche ergeben. Ein zertifizierter Betrieb nach ISO 27001 auf Basis ITGrundschutz führt bei einem solchen Modell aber fast automatisch dazu, dass im Zuge des Maximalprinzips auf praktisch alle Komponenten ein hoher Schutzbedarf zukommt. Nur so wäre es möglich, fallweise das Schutzniveau anheben zu können. Dieser Vergleich soll zeigen, worum es geht: um die Maßnahmen im Hintergrund zur Absicherung der Infrastruktur, die nicht als zusätzlicher Service abgebildet werden können. Der zweite Ansatz versucht eine Automatisierbarkeit durch die Vorgabe weniger interpretationsbedürftiger Aussagen zu erreichen. Die Definition des Schutzniveaus entfällt 96

Bundesamt für Sicherheit in der Informationstechnik

Resümee und Ausblick 8

zugunsten einer vollständigen Abdeckung der technischen Maßnahmen. Um nicht an einer kaum zu beherrschenden Komplexität zu scheitern, wird die Definition auf einer höheren Ebene anhand von Standards erbracht. Als einziger allgemeingültiger Standard bieten die IT-Grundschutzkataloge des BSI die notwendige technische Detailtiefe der Maßnahmen, Die zukünftige Machbarkeit von automatisierten PLA-Verhandlungen in Service-orientierten Architekturen hängt von der Entwicklung von stark standardisierten Komponenten mit ebenso standardisierten Sicherheitsanforderungen ab; nur in solchen Spezialfällen wird ein Einsatz sinnvoll umsetzbar sein. Im Bereich des klassischen Vertragsbeziehung zwischen Dienstleister und Kunde ist eine strukturierte Einbeziehung der Sicherheitsanforderungen des Kunden überfällig. In der heutigen Praxis werden die Anforderung oft nicht ausreichend definiert und häufig nicht oder nicht vollständig an Subunternehmer weitergegeben. Die in Kapitel 5 dargestellte Struktur eines PLA kann als Grundlage für einen Vertrag dienen, der die Sicherheitsanforderungen umfassend definiert und trotzdem nicht an seiner eigenen Komplexität scheitern muss. Bei steigendem Einsatz von PLAs bzw. PLA-ähnlichen Vereinbarungen wird das Interesse von Dienstleistern an zertifizierbarer Sicherheit stark zunehmen. Hier besteht auch die Chance, dass sich für hoch standardisierte Services eigene Sicherheitsstandards herausbilden, die dann wiederum den Kunden mehr und einfachere Möglichkeiten zur Definition seiner Sicherheitsanforderungen bringen.

Bundesamt für Sicherheit in der Informationstechnik

97

9 Anhang

9

Anhang

9.1

Glossar

Das Glossar erklärt Fachbegriffe, die in den unterschiedlichen Kapiteln verwendet werden. Begriff/Abkürzung

Erläuterung

Identity-Provider

Identitätsdienstleister; bietet einen Dienst zur Authentifizierung und zur Bereitstellung von Identitätsinformationen von Service-Consumern an Service-Provider

ISMS

Information Security Management System. Bezeichnet den Prozess zum Management der Informationssicherheit in einem Unternehmen als Übergruppe der IT-Sicherheit.

ISO 20000

ISO-Standard zum IT-Service-Management; Beschreibung von Anforderungen für die Umsetzung eines IT Service Managements (ITSM)

ISO 27001

ISO 27001 spezifiziert die Anforderungen an ein InformationssicherheitsManagementsystem (ISMS)

ISO 27002

ISO 27002 dokumentiert Best-Practice-Ansätze für Sicherheitsmaßnahmen im Rahmen eines ISMS. Im Gegensatz zu den ITGrundschutz-Katalogen sind diese Maßnahmen nicht zertifizierbar.

ITIL

IT Infrastructure Library (ITIL® V3): Beschreibung von Best Practices für die Umsetzung eines IT Service Managements (ITSM); De-Fakto Standard

ITSM

IT Service Management; bezeichnet die Methoden zum Management der IT-Organisation als Unterstützung für die Geschäftsprozesse

KPI

Key Performance Indicator

OLR

Operational Level Agreement: Interne Vereinbarung z. B. mit Betriebsreferaten zur Absicherung einzelner Servicekomponenten und Betriebsbestandteilen eines IT-Services.

PKI

Public Key Infrastructure: Infrastruktur zur Verwaltung von digitalen Zertifikaten (Erstellung, Verifikation, Widerruf)

Policy Enforcement

Bezeichnet die meist automatisierte Umsetzung bzw. den Punkt der Umsetzung von Sicherheits-Policies durch restriktive Maßnahmen.

Service (Dienst)

Bezeichnet eine Dienstleistung im Sinne von SOA. Ein Dienst bietet eine Funktionalität inklusive der dafür benötigten Ressourcen über eine standardisierte Schnittstelle an.

Service-Broker

Verzeichnisdienst für von Service-Providern angebotene Services (Dienste). Der Broker kann eine Vertrauensstellung einnehmen, wenn er

98

Bundesamt für Sicherheit in der Informationstechnik

Anhang 9

Begriff/Abkürzung

Erläuterung bestimmte Garantien für die angebotenen Services abgibt oder alleine für die Versorgung mit Diensten zuständig ist.

Service-Consumer

„Service-Consumer“ bezeichnet den Kunden eines Dienstanbieters in einer SOA. Der Service-Consumer nutzt einen Service.

Service-Provider

„Service-Provider“ bezeichnet den Anbieter eines Dienstes in einer SOA. Der Anbieter hält die Ressourcen vor und gibt dem Consumer gegenüber Garantien ab.

SIP

Service Improvement Plan (Service-Verbesserungsplan); formeller Begriff aus ITIL; Teil des Prozesses Continual Service Improvement (CSI)

SLA

Service Level Agreement; Vertrag zur Vereinbarung von Service-Qualität und Funktionalität in einer Kunde-Dienstleister-Beziehung.

SLM

Service Level Management; Prozess zum Management von SLAs.

SLR

Service Level Requirement: Dokument, in welchem Anforderungen an ITServices und Servicequalitäten gemeinsam mit dem Kunden bzw. Interessenten erhoben werden. Es dient als Grundlage für die Ausgestaltung des SLA.

SOA

„Service-orientierte Architektur“ bezeichnet ein IT-Architekturkonzept, das Geschäftsprozesse durch lose gekoppelte, wiederverwendbare Dienste (Funktionalität und Ressourcen) umsetzt. In diesem Dokument wird SOA meist synonym mit der spezifischen Umsetzung dieser Architektur mittels Web-Services verwendet.

SOAP

Netzwerkprotokoll zur Durchführung von Remote Procedure Calls mittels XML. Die häufigste Übertragungsart ist HTTP.

Web-Service

Ein Web-Service ist eine über HTTP aufrufbarer Dienst. Implementiert werden Web Services am häufigsten als mittels SOAP aufrufbarer Methoden.

WS-*

Die WS-*-Reihe von Spezifikation definiert Sicherheitsmechanismen für Web-Service-basierte SOA und wird von der Organization for the Advancement of Structured Information Standards (OASIS) herausgegeben.

WSDL

Web Services Description Language: XML-basierte Beschreibungssprache für Webservices. WSDL definiert die Schnittstelle von Webservices so, dass eine (begrenzt) automatisierte Nutzung unbekannter Services möglich ist.

Tabelle 26: Glossar

Bundesamt für Sicherheit in der Informationstechnik

99

9 Anhang

9.2

Literaturverzeichnis

ISO 27001

IT-Sicherheitsverfahren - Informationssicherheits-Managementsysteme Anforderungen, DIN ISO/IEC 27001 InformationssicherheitsManagementsysteme - Anforderungen

EGov2.0

Bundesministerium des Innern | IT-Stab: E-Government 2.0 - Das Programm des Bundes, 1. Auflage, Berlin: Publikationsversand der Bundesregierung, 2006

ITIL 2007

The Office of Government Commerce (OGC): ITIL® Version 3 - Service Design,TSO, 2007

ISO 20000

British Standard - BSI: BS ISO/IEC 20000-1:2005

ITIL Glossar

itSMF Arbeitskreis Publikationen: ITIL® V3 Glossar, itSMF 2007

SLA-DissertationThomas Berger: Konzeption und Management von Service Level Agreements für IT-Dienstleistungen, Dissertation, TU Darmstadt, 2005 ITIL-CSI

The Office of Government Commerce (OGC): ITIL® Version 3 - Continual Service Improvement,TSO, 2007

SLM ÖV

Markus Bonk et al.: Service Level Management in der Öffentlichen Verwaltung, 1. Auflage, Symposion Publishing, Düsseldorf: 2010

Grundsch 2009 Bundesamt für Sicherheit in der Informationstechnik (BSI)ITGrundschutzkataloge, 11. Ergänzungslieferung Kara 06

Karabulut, Y.; Kerschbaum, F.; Robinson, P.; Massacci, F.; Yautsikhin, A, Security and Trust in IT Business Outsourcing: a Manifesto, 2006

Veren 09

Vilhelm Verendel Quantified Security is a Weak Hypothesis, Chalmers University

OASIS 2004

OASISWeb Services Security: SOAP Message Security 1.0 (WS-Security 2004)

TAM

Adams, Dennis A. et al. Perceived usefulness, ease of use, and usage of information technology: a replicstion; Society for Information Management and The Management Information Systems Research Center, Minneapolis, MN, USA, 1992, MIS Quarterly 16-2, p. 227-247

ISO 27002

IT-Sicherheitsverfahren - Leitfaden für das Informationssicherheits-Management, DIN ISO/IEC 27002

Guti2005

C Gutiérrez, E Fernández-Medina, M Piattini Web Services Enterprise Security Architecture: A Case Study

Mora2009

A. Moralı and Roel Wieringa Risk-Based Confidentiality Requirements Specification for Outsourced IT Systems, Centre for Telematics and Information Technology, University of Twente, 2009

Abed2006

M.Abedin et. al Vulnerability analysis For evaluating quality of protection of security policies, Proceedings of the 2nd ACM workshop on Quality of protection, ACM, NY, 2006

Vach2009

Geraldine Vache Vulnerability analysis for a quantitative security evaluation, Proceedings of the 2009 3rd International Symposium on Empirical Software Engineering and Measurement, 2009

100

Bundesamt für Sicherheit in der Informationstechnik

Anhang 9

Mass2007

F. Massaci and Artsiom Yautsiukhin An algorithm for the appraisal of assurance indicators for complex business processes, Proceedings of the 2007 ACM workshop on Quality of protection, 2007

BSI-SOA 2009

SOA-Security-Kompendium, Sicherheit in Service-orientierten Architekturen, Bundesamt für Sicherheit in der Informationstechnik, Version 2.0, 2009

Ecke2007

Claudia Eckert, Björn Steinemann, Tobias Wahl SOA und Sicherheit, Web Service Security Praxis und offene Probleme, Datenschutz und Datensicherheit (DuD) 31, 2007

WS-Pol2007

W3CWeb Services Policy 1.5 - Framework

PCI-DSS 2009

PCI Security Standards Council Payment Card Industry Data Security Standard (PCI DSS), Version 1.2.1, 2009

9.3

Stichwort- und Abkürzungsverzeichnis

Administrator..........................................................................................................................37, 54, 60 ADS (Active Directory Services).......................................................................................................27 Aktive Inhalte......................................................................................................................................... Flash...............................................................................................................................................60 AR (Access rate).................................................................................................................................76 Archiv...............................................................................................................................................56f. Authentifizierung..............................................................................................................39, 48, 53, 98 Authentisierung....................................................................................................................59f., 89, 92 Authentizität...........................................................................................................................53, 56, 88 Baustein................................................................................................................24, 31, 42f., 76, 93ff. BDSG (Bundesdatenschutzgesetz).....................................................................................................57 Betriebssystem....................................................................................................................................31 Bit (Binary Digit)...............................................................................................................................60 CC (Common Criteria).................................................................................................................43, 61 Datenschutz.....................................................................................................................................56ff. Datensicherung...................................................................................................................................59 Diensteanbieter...................................................................................................................................93 DSS (Digital Signature Standard)................................................................................................58, 96 DV (Datenverarbeitung).....................................................................................................................56 DV (Digital Video).............................................................................................................................56 E-Mail (Electronic Mail)..........................................................................................2, 8, 18, 27, 52, 78 EAI (Enterprise Application Integration)...........................................................................................86 EAL (Evaluation Assurance Level)....................................................................................................43 Bundesamt für Sicherheit in der Informationstechnik

101

9 Anhang

EG (Europäische Gemeinschaft)........................................................................................................57 FIPS (Federal Information Processing Standard)............................................................................60f. Firewall.........................................................................................................................................43, 94 Flash...................................................................................................................................................60 Framework................................................................................................................................39, 92ff. Gefährdung...................................................................................................................................45, 94 Gefährdung............................................................................................................................................. Spam........................................................................................................................................52, 58 Gesetz..................................................................................................................................................... BDSG (Bundesdatenschutzgesetz)................................................................................................57 Grafik............................................................................................................................................46, 94 Hardware....................................................................................................................................16, 31f. Hash............................................................................................................................................39, 60f. HTTP (Hypertext Transfer Protocol).................................................................................................99 Hub.....................................................................................................................................................10 Informationssicherheit............................................................................................................44, 56, 98 INFOSEC (Information Security)......................................................................................................98 Integrität...........................................................................................34, 39, 44f., 48, 53ff., 58f., 88, 94 Intranet................................................................................................................................................38 ISMS (Information Security Management System)...............................................................7, 31f., 98 ISO (International Organization for Standardization)................................7, 31, 37, 42, 58, 76, 96, 98 IT-Grundschutz..................................................................................7, 31f., 37, 42, 58, 76, 94, 96, 98 IT-Grundschutz....................................................................................................................................... IT-Grundschutz-Katalog..........................................................................................................31, 98 IT-SiBe (IT-Sicherheitsbeauftragter)...........................................................................................62, 68 IT-Sicherheit........................................................................................................................83, 92f., 98 IT-Sicherheit........................................................................................................................................... Authentizität.......................................................................................................................53, 56, 88 Informationssicherheit.......................................................................................................44, 56, 98 Integrität...............................................................................................34, 39, 44f., 48, 53ff., 88, 94 Nichtabstreitbarkeit........................................................................................................................56 Verfügbarkeit...........................................10, 17, 20, 28, 32, 34, 36, 38f., 44, 46, 48f., 52ff., 94, 96 Vertraulichkeit................................................................25, 33f., 37, 39, 44f., 48, 50f., 53f., 88, 94 IT-Sicherheitsbeauftragter......................................................................................................62, 68, 78

102

Bundesamt für Sicherheit in der Informationstechnik

Anhang 9

IT-Sicherheitskonzept.........................................................................................................................31 IT-Sicherheitsmanagement...........................................................................................................42, 46 ITSEC (Information Technology Security Evaluation Criteria)........................................................61 LDAP (Lightweight Directory Access Protocol)...............................................................................27 MD5 (Message Digest Algorithm 5)..................................................................................................39 Nichtabstreitbarkeit............................................................................................................................56 NIST (National Institute of Standards and Technology, USA)..........................................................60 OASIS (Organization for the Advancement of Structured Information Standards)....................88, 99 Passwort........................................................................................................................................59, 61 Patch.....................................................................................................................43, 56, 59, 63, 90, 93 PC (Personal Computer).....................................................................................................................22 PCI (Peripheral Component Interconnect)...................................................................................58, 96 PKI (Public Key Infrastructure)...................................................................................................61, 98 PL (Physical Layer).........................................................................................68f., 71, 73f., 76f., 79ff. PLA (Protection Level Agreement)......................................................................................33ff., 41ff. PLM (Phase Length Modulation)...........................................................................................65ff., 83f. Protokoll................................................................................................................................................. HTTP (Hypertext Transfer Protocol).............................................................................................99 LDAP (Lightweight Directory Access Protocol)...........................................................................27 SOAP.......................................................................................................................................88, 99 Prüfsumme..........................................................................................................................................55 QoP (Quality of Protection)................................................................................................................33 QoS (Quality of Services)..................................................................................................................33 RAID (Redundant Array of Inexpensive (Independent) Disks).........................................................43 Redundanz..........................................................................................................................................43 Risiko....................................................................................................................31, 35, 38, 40, 45, 48 Risikoanalyse................................................................................................................................35, 93 SAN (Storage Area Network)............................................................................................................31 SAP (SAP)..........................................................................................................................................32 SAP (Service Access Point)...............................................................................................................32 SC (Subcommittee)............................................................................................68f., 71, 73, 76, 79, 82 Schadprogramm...................................................................................................................................... Virus...............................................................................................................................................58 Schutzbedarf...................................................................................................35, 40, 43, 47, 58, 71, 96

Bundesamt für Sicherheit in der Informationstechnik

103

9 Anhang

Schutzbedarf........................................................................................................................................... Schutzbedarfsfeststellung..............................................................................................................71 Schwachstelle.......................................................................................................33, 36, 45, 59, 63, 77 SHA (Secure Hash Algorithm)...........................................................................................................39 SHA-1 (Secure Hash Algorithm 1)....................................................................................................39 Sicherheits-Gateway............................................................................................................................... Firewall....................................................................................................................................43, 94 Sicherheitsbeauftragte......................................................................................................62, 68, 72, 78 Sicherheitskonzept............................................................................................................31, 39, 43, 95 Sicherheitsleitlinie..............................................................................................................................54 Sicherheitsmaßnahme.................................................................................35, 41, 46, 88, 90, 92ff., 98 Sicherheitsziel..............................................................................................39, 44, 46f., 53ff., 57f., 65 SIP (Session Initiation Protocol)................................................................................................81f., 99 SLA (Service Level Agreement)..............................7, 9ff., 15ff., 32ff., 36, 38, 49ff., 55, 63ff., 96, 99 SOA (Start Of Authority)...........................................................7, 36, 47, 56, 59, 85ff., 90, 92ff., 98f. SOAP............................................................................................................................................88, 99 SP (Service Pack).................................................................................................68, 71, 73, 76, 79, 82 Spam.............................................................................................................................................52, 58 Tag..........................................................................................................................................28, 34, 77 Überweisung.......................................................................................................................................44 Verfügbarkeit...............................................10, 17, 20, 28, 32, 34, 36, 38f., 44, 46, 48f., 52ff., 94, 96 Vertraulichkeit.....................................................................25, 33f., 37, 39, 44f., 48, 50f., 53f., 88, 94 Virenschutz.........................................................................................................................................96 Virus.......................................................................................................................................41, 58, 96 WORM (Write Once, Read Many)....................................................................................................57 WSDL (Web Services Description Language).............................................................................86, 99 XML (Extensible Markup Language)........................................................................................87f., 99 XSS (Cross-Site Scripting).................................................................................................................45 Zeitstempel...................................................................................................................................57, 87 Zertifikat..............................................................................................37f., 42, 59, 71, 73, 93f., 96, 98

104

Bundesamt für Sicherheit in der Informationstechnik