Techniken um Multi-Service Provider Umgebungen in der Sicherheit zu verwalten – Der Lead Provider

SECTANK ICE

Das Problem

Die Welt dreht sich schneller und schneller. Als die ISO/IEC 27001:2005 um 2005 geboren wurde, war die Globalisierung auf einem Hochpunkt, ebenso wie deren IT-technische Vernetzung und Abhängigkeiten. Wir dachten, das Maß sei schon erreicht, aber die Realität lehrte uns, dass es noch ein Level besser geht. Cloud Computing war geboren. Viele sagten, dass Cloud ja nichts neues sei, dass man das alles schon gehabt hätte, und es nur ein wenig anders sei, als das klassische Outsourcing. Weit gefehlt.

Als allererstes gingen uns die Standards aus. BSI Standards 100-1, 100-2, 100-3 bzw. ISO 27001 auf Basis von IT Grundschutz, und Cloud? Auch die BSI-Standards sind perfekt, wenn man sich den Artikel zum Thema Grundschutz und Cloud Computing durchliest: Wie reitet man ein totes Pferd. (vgl. Security Corner in der Computer Zeitung, Konradin-Verlag, online-Ausgabe). Aber auch nicht das Gelbe vom Ei.

Vorreiter gibt es, z.B. die T-Systems mit den ESARIS-Standards, vom Team von Prof. von Faber  entwickelt, geniale Standards, die nunmehr nicht nur ein Theoriepaket sind,wie am Anfang, sondern voll in die operative Praxis von der TSI eingebettet wurden. Auch das BSI hat mittlerweile ein Cloud Modul.

Stellen Sie sich folgendes Szenario vor. Nehmen wir an, man wäre ein Finanzbranchenkunde. Und dieser bezöge von der TSI ESARIS Cloud Services für das Servermanagement, Infrastrukturmanagement und Netzdienste, von einer ATOS Desktopservices, dann greift man beim Provider FI-TS auf Anwendungen zu, und dann muss man in einem Multi-Plattform-Projekt, in das noch eine weitere Mutterbank mit Anwendungen integriert ist, eine Statistiksoftware im Risikomanagement noch den BCBS239 ausrollen (Basel III). Jetzt stelle man sich noch vor, man wäre der Verantwortliche für dieses Sicherheitskonzept.

Die Standards aller Teilnehmer im Projekt sind unterschiedlich. Also maximal 5 verschiedene Sicherheitsstandards. ESARIS, DIN ISO, BSI Grundschutz, Cobit und dann noch den BCBS im Projekt umsetzen, und eigene Sicherheitsrichtlinien gibt es auch noch, allerdings nach keinem Standard.

Solche Siko landen täglich auf meinem Schreibtisch. Ist das ein Problem? Nein, ich verdiene mein Geld damit, ich mache das gerne. Ist das sinnvoll? Nun ja, 2005 drehte sich die Welt in der IT noch ein klein wenig anders. Diese Art von Siko bekommt man durch Mapping vom Maßnahmen und Anforderungen immer hin. Die Frage ist nur, welcher Aufwand ist es? Wie viele Fehler schleichen sich ein? Ist es wirklich rund an der einen oder anderen Stelle, oder gibt es noch Verträge hier und da, die auch noch SLA oder SSLA sprechen, und einen weiteren semantischen Bruch in das Sicherheitsgewerk reißen?

Ich finde es mittlerweile unterirdisch das Problem Sicherheit zu verwalten in einer Multi-Service Provider Umgebung so anzugehen, wie wir es heute exerzieren. Das Mapping ist sehr komplex, dass es jemanden wie mir nach 25 Jahren Sicherheit schon schwer fällt hier und dort, und wo ich mich beim Kunden gerade nicht überwältigend auskenne. Nun stelle man sich vor, dass das dann bei der einen oder der anderen Firma noch viele externe machen, die nicht wissen, was wieso historisch gewachsen ist usw. Das Chaos ist uns vorprogrammiert.

Nach einem tiefgründigen Gespräch mit Dr. Wolfgang Böhmer letzte Woche, hat dieser mir das Phänomen bestätigt. Dr. Böhmer verwies auf den ISO/IEC 22301, der als einziger Standard das Problem in Sachen Lieferketten und Abhängigkeiten in extremen Situationen betrachtet. Dieses jedoch im vorliegen Wirkbetrieb nicht ausreicht.

Alle machen munter weiter.  Und gerade bei Finanzinstituten sind die Anforderungen so streng geworden, dass sie dieses Mapping auf Biegen und Brechen durchmappen müssen. Die Kosten sind immens, die Verwaltung wird immer schwieriger, und die Fehlerrate ist hoch.

Das Problem bei Managed Services ist, dass keiner der großen Dienstleister einen Kundenstandard adaptieren wird. Sie Mappen auf der Gegenseite die Anforderungen genauso wie auf der Kundenseite, evt, einige Dimensionen einfacher, aber dennoch. Auch hier schleicht sich der Fehlerteufel ein, auch hier wird ein nicht unbeachtliches Budget dafür vorgesehen, was der Kunde mit bezahlen muss.

Die Abhandlung

Es folgt eine Abhandlung, wie man diesem Problem Herr werden kann. Dazu muss aber generell die Bereitschaft bestehen, noch mehr Dinge aus der Hand geben zu wollen.

Finanzinstitute unterliegen einer Vielzahl von Dienstleistern, die eine große Vielfalt an Technologie-bezogenen Funktionen unterstützen. Das Outsourcing in Form des klassischen Outsourcings oder Cloud Computings hat definitiv Vorteile. Man kann sich beste Technik für den besten Preis leisten.  Aber diese Vielfalt hat auch Einfluss auf das Risikoprofil des Finanzinstitutes. Risikomanagement Prozesse werden durch Outsourcing über mehrere Dienstleister und Partner verteilt, und müsste eigentlich einem koordinierten Vertragsübersicht-Modell durch das Bankenmanagement unterliegen.

An dieser Stelle sollen zwei Modelle vorgestellt werden, um Risiken in Multi-Service-Provider-Umgebungen zu managen. Als erstes wird dargestellt, wie man einen verantwortlichen Vertragspartner einsetzt, der einem die Dienstleister verwaltet.  Das zweite Modell beschreibt, wie man durch ein eigenes Set von Implementierungsanforderungen, operationelle Vereinbarungen trifft zwischen allen Dienstleistern.

Ein oder mehrere Dienstleister liefern einen verteilten Service, der gemeinsam eine Anforderung der Bank erfüllt. Die Art der Verträge für diese verteilten Dienstleistungen variieren auf dem Markt. Viele Institute arbeiten mit einem Lead Provider, der in der Praxis ein Unterauftragnehmer zwischen der Bank und jedem ihrer Services Provider wird. Einzelverträge mit den Dienstleistern sind eher die Regel und stellen noch immer mehr als 90% der Verträge auf dem Markt dar.

Welchen Lead Service Provider man auswählen kann, ist unterschiedlich. Bei einer Hauptanwendung, bei der man sich von einem Dienstleister die Anwendung liefern lässt, andere nur Netz, Proxy und evt. Cloud Storage liefern lässt, liegt es nahe dem Anwendungsdienstleister das Lead Management zu erteilen. Schließt man Einzelverträge mit den einzelnen Dienstleistern, erhöht dies das tägliche Management mit jedem einzelnen Provider. Dies impliziert einen Anstieg der Koordination, der Schedule und Performance Probleme und der Komplexität. An dieser Stelle reduziert ein Lead Provider für eine Bank das Leid des Nicht-Erreichens der Ziele eines Dienstleisters bzw. eine Verspätung im Projekt. Der Lead Provider kümmert sich in diesem Falle um die Zieleerreichung der einzelnen involvierten Dienstleister im Auftrag der Bank.

Für das Risikomanagement bedeutet das, dass die bestpassende Risikomanagementstrategie berücksichtigt wird. Der Lead Provider wird Inter-Provider Service Level Agreements berücksichtigen, die die Risiken auf die Bank im Providerverhältnis berücksichtigen. Hier wird das manuelle Mapping in einem ersten Schritt erst einmal nur verlagert.

Die Struktur einer Lead Provider Organisation kann vertraglich festgelegt Top-Down sein, oder sich auch aus einem Vertragsverhältnis ergeben, in dem mehrere Provider sich auf eine Ausschreibung als ein Team bewerben. Egal ob der Verhältnis des Lead Provider und der Bank schon existierte, gibt es Techniken und Ansätze, die das Bankenmanagement nutzen kann um Risiken zu managen. Im Statement of Work könnten zum Beispiel schon Rollen festgelegt werden, die die Verantwortlichkeiten regeln.

Der Lead Provider kümmert sich in der Regel um alle Aspekte eines Vertrages. Das vertragliche Gerüst mit dem Lead Provider, in dem sein Auftrag beschrieben ist, reduziert die restliche rechtliche Komplexität im Gesamtvertragsverhältnis mit allen Providern immens. Es ist im Grunde genommen, wie ein Vertragsverhältnis. So verhält es sich auch bei Sicherheit und Risiken.

Aber welchen Lead Provider wählt man? Das ist recht einfach. Normalerweise ist das der größte Provider, mit dem man am meisten Geschäfte macht. Nun gibt es Kunden, die haben ein 30% zu 30% zu 30% zu 10% – Providersplitting. Hier ist es evt. sinnvoll den Provider zu wählen, der die kritische Infrastruktur managed.

Was zeigt sich dabei als schwierig im Lead Provider Management? Kritisch ist z.B. die Haftungsfrage. Viele Provider haben eine maximale Haftungsgrenze für Vermögensschäden. Meist nimmt der Lead Provider die Haftung für seine Unterauftragnehmer auf sich, und legt dabei eine Obergrenze pro Unterauftragnehmer fest. Hier ist die Rechtsabteilung der Bank gefragt, ob diese Obergrenzen ausreichend sind. In den USA, wo solche Modelle am meisten verbreitet sind gibt es den Ausdruck “Privity”. Privity ist in den USA ein terminologischer Ausdruck im Recht. “A relation between parties held to be sufficiently close and direct to uphold a legal claim on behalf or against another party with whom this relation exists”. Ein Nachteil. Die direkte Privity der Bank auf die einzelnen Dienstleister wird reduziert.

Bei einem Lead Provider muss man vertraglich mit Inter-Provider-SLAs arbeiten, und Achtung bitte jetzt für die Sicherheitsleute, mit Inter-Provider-SSLAs. Diese benötigt der Lead Provider um die Performance der anderen beteiligten Provider zu messen. Dadurch steigt aber auch der Kommunikationsfluss zwischen den Providern, den man normalweise in Einzelverhältnissen nicht hat. Das ist ja gerade das Ziel. Den Bottleneck zwischen einzelnen Providern und der Bank zu eliminieren, der normalerweise aus Einzelvertragsverhältnissen entsteht. Man muss dabei als Bank die Oberhand auf das Vertragswerk mit dem Lead Provider haben, und dem des Lead Providers mit dem Unterauftragnehmer. Das ist im ersten Moment viel mehr Vertragswerk, aber es spart im Nachhinein immense Arbeit und Kosten. Übergabepunkte müssen definiert werden. Mindestanforderungen an akzeptable Dienstleistungen müssen entwickelt werden. Mindestservicelevels müssen abgestimmt und harmoniert sein, Mindestperformance-Standards und entsprechende Messwerkzeuge müssen festgelegt werden. Hier einige Regeln:

  • Die Bank muss genau sein in der Definition der Verantwortlichkeit. Nehmen Sie den Lead Provider in die Pflicht der Hauptverantwortung. Jeder involvierte einzelne sollte seine Aufgabe genau kennen
  • Folgende Vorkehrungen sind zu treffen: Regelungen für Nachverhandlungen, Wiederauswertung, Austrittsstrategien,etc.
  • Vertragliche Regelungen müssen das Unterauftragsnehmerverhältnis festlegen, die Umstände für ausdrückliche Genehmigung des wer darf ausgewählt werden um welche Funktion zu erfüllen
  • Es ist zu regeln, wann neue Provider in das Verhältnis eingebunden werden dürfen. Diese Regelung hilft die Tendenz bei Service Provider zu minimieren, neue Provider in das Verhältnis aufzunehmen, weil man es selbst machen will, was aber evt. für die Bank die Produktivität einschränken kann
  • In der Bank sollte die Fähigkeit aufrecht erhalten werden, das gesamte Vertragsverhältnis effektiv zu verwalten, auch wenn sich die Bank stark am Lead Provider oder der Vertragsfirma, die mit der Verwaltung beauftragt ist, orientiert
  • Alle Provider sind darauf zu verpflichten die bereitgestellten Lösungen dafür bereitzustellen, um einen Wechsel zu jeder Zeit zu einem anderen Unterauftragnehmer verwirklichen zu können

Es sind einige weitere vertragliche Regelungen zu definieren, die einen reibungslosen Lead Provider Einsatz in einer Multi-Service Provider Umgebung möglich machen. Auf Einzelheiten möchte ich an dieser Stelle nicht eingehen. Die Absicht in diesem Artikel liegt erst einmal darin, dass man überhaupt erst einmal ein offenes Ohr dafür entwickelt, sich so eine Umgebung vorstellen zu können.

Ich bin durch das Mapping von hunderten von Sicherheitsanforderungen unterschiedlicher Sicherheitsstandards vieler Provider dazu gekommen, meinen Kunden über die Sicherheit in seiner gesamtvertraglichen Situation zu beraten, und es stieß auf viele offene Ohren.

Da in Deutschland dieses Konzept noch nicht so stark verbreitet ist, auch nicht bei Banken, muss man das Thema als verantwortlicher Berater sachte angehen. Man kann viel kaputt machen. Einzelverträge mit Providern verantwortlichen Mitarbeitern aus der Hand zu nehmen, um sie dem Lead Provider zu geben, sorgt in einer Organisation für viel Unruhe. Leute fühlen sich nicht mehr benötigt, die Angst kursiert einen Arbeitsplatz zu verlieren oder ausgelagert zu werden, obwohl in einer gesunden Organisation die Mitarbeiter weiterhin benötigt werden. Betriebsräte denken natürlich anders darüber.

Aber auch Provider machen einem das Leben schwer. Arbeitet man bei der TSI in einer Cloud und bittet sie z.B. mit Hilfe der ESARIS Standards auch andere Provider zu managen, das sorgt für Probleme. Der Konkurrenz solche Standards bereit zu stellen? Oder evt. ist der andere Provider gar nicht operativ für diese hohen Standards aufgestellt, und schafft das evt. auch nicht, in einer für das Projekt evt. angemessen Zeit, zu implementieren? Aber das Mapping von Sicherheitsmaßnahmen oder Anforderungen / Risiken ist dann wenigstens vertraglich zu verlagern.

Die Sicherheitsabteilungen der Bank und jeder Firma, die ein solches Modell verfolgt sind nun gefragt. In 2000 oder 2005 erstellte Sicherheitsrichtlinien mögen einmal ihren Sinn gehabt haben. Diese stellen die “Ich-Situation” (nicht IST-Situation) des Unternehmens dar, damit meine ich die Sicherheit aus der Sicht der Bank. Nehmen wir an eine Bank hat keinen etablierten Sicherheitsstandard wie den Grundschutz oder die DIN ISO, Cobit, etc., und nehmen wir weiterhin an, Bank bedient sich in einer 30% – 30% – 30% – 10 %- Verteilung von Dienstleistern für die 30% Services Desktop, 30% Infrastruktur, Server und Netze, 30% Anwendungen und 10% alles mögliche. Der eine 30%-Anbieter arbeitet mit Grundschutz, der weitere 30%  mit ESARIS, ein weiterer 30% mit DIN ISO und 10% haben keinen etablierten Standard, oder alles mögliche, z.B. nur eigene Policies.

In diesem Falle machen die eigenen Richtlinien der Bank nur noch sehr beschränkt Sinn für das Providermanagement, ansonsten nur Arbeit und Chaos in der heutigen Outsourcing-Situation. Mapping Mapping Mapping.

Fazit

Sicherheitsabteilungen einer Bank mit Multiserviceprovider-Umgebungen müssen lernen, nur noch kleine schlanke Richtlinien für die Mindestsicherheit der Core-Systeme der Bank zu entwickeln. Das Risikomanagement muss auf die Multiserviceproviderumgebung abstimmt sein. Die TOM ADVs für die Auftragsdatenverarbeitung auch. Ansonsten müssen sie in Zukunft lernen, den Standard eines Lead Providers zu akzeptieren, schnell für die eigenen Umgebung operativ einzubetten und zu integrieren, und über Lead Provider Vertragsmanagement den anderen Providern aufzunötigen. Wechselt man den Lead Provider, sind die Sicherheitsbestimmungen an den neuen Lead Provider anzupassen. Das kann alle 3-5 Jahre wechseln.  Sicherheitsabteilungen einer Bank legen mit ihren Richtlinien kein Bollwerk für die Ewigkeit fest. Das ist der Wunsch einer jeden Sicherheitsabteilung, doch völlig unzeitgemäß, und in der Praxis auch nicht funktionsfähig.

Die legislative Unternehmenssicherheit hat heute keine reine Aufgabe mehr ein reines Richtlinienregelwerk vorzuhalten, und World sich daran ausrichten zu lassen. Das sind alte unzeitgemäße Diktaturen, die mit einer operativen Sicherheitsrealität und -Qualität nichts mehr zu tun haben. Würden die Damen und Herren öfters einmal ein wenig Produktionsluft schnuppern, und sehen, wie kompliziert eine Umsetzung eines solchen Regelwerkes heute geworden ist in einer Multiserviceprovider-Umgebung, das würde allen gut tun. Mittlerweile sehe ich das Richtlinienwerk einer Bank immer mehr den Platz zwischen Vertrag und operativer Sicherheit einnehmen. Allerdings meist nur noch mit einer negativen Note belegt, also eher arbeitsbehindernd als lösungsorientiert. Dann würde es für mich mehr Sinn machen die Sicherheitsrichtlinien auf einem OSI-Layer Modell vorzuschreiben. Damit kann die Produktion in jedem Fall mehr anfangen.

Service Provider müssen sich in Zukunft darauf einstellen, dass Ihr gesetzter Standard durchaus auch für ein Lead Provider Vertragsverhältnis mit Dritten Providern bereitgestellt werden muss, und müssen dies erlauben.

Sicherheit sollte so einfach wie die alltäglichen Dinge des Lebens sein.

Alexander Tsolkas

 

 




Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden .