Security by Service-Design

Von Andreas Dassen, Eschweiler, David Fuhr, Berlin, und Martin Glaser, Frankfurt/Main

Trotz allgegenwärtig zunehmender Sicherheitsvorfälle wird Security meist immer noch in einem von zwei Modi betrieben: entweder nach dem Gießkannenprinzip der Compliance („Überall muss ein Mindestmaß an DSGVO drin sein!“) oder nach der Rettungsdienstlogik („Vorfall oder Buzzword ➝ Management Attention ➝ Aktivismus“), bisweilen mühsam getarnt durch das Label der „Risikobasiertheit“. Nur äußerst selten folgt das Sicherheitsprogramm systematischen Grundsätzen, die einer Ingenieurswissenschaft würdig wären.

Zwar gibt es in der (Software-)Entwicklung mit „Security by Design“ ein wichtiges Paradigma, das hilft, Sicherheit frühzeitig und ganzheitlich im Code zu verankern. Dies zielt jedoch in der Regel auf einzelne Anwendungen oder Produkte ab und ist damit aufwendig und immer individuell umzusetzen. Nicht betrachtet wird dabei der spätere Lebenszyklus, mithin Einsatzzweck und Daseinsberechtigung der Produkte, also die Service-Erbringung. Für die betriebenen und angebotenen Services kommt dabei angemessene Security, wenn überhaupt, eher zufällig heraus und wird häufig angesichts neuer Bedrohungen, Technologie oder sonstiger veränderter Anforderungen nicht dauerhaft an neue Situationen angepasst.

Chief-Information-Security-Officer (CISO) oder Informations-Sicherheits-Beauftragter (ISB) agieren in dieser Welt als Feuerwehr und Brandschutzbeauftragte in Personalunion, sind aber in der Regel weder in die Bauplanung noch in das „Facility-Management“ der IT-Welten systematisch einbezogen.

Schaut man auf das Service-Management, macht ein Blick in die „Information Technology Infrastructure Library“ ITIL4 schnell klar, dass auch hier Security nur als reaktive Komponente betrachtet wird: In der ITIL Praxis sind nur die zwei Prozesse „Security Incident“ sowie „Audit & Review“ vorgesehen, und auch in der Practice „Service Design“ wird lediglich erwähnt, dass man sich um Security kümmern muss.

Somit existiert in der Praxis kein abgestimmtes Vorgehen zwischen CISO/ISB und Service-Management – Security wird im Wesentlichen „eventbasiert“ betrieben: Die DSGVO, der Incident, die Geschäftsführung sagen, dass etwas getan werden muss, und das wird dann punktuell in Angriff genommen.

Das kann nicht nachhaltig sein in einer Welt, in der Organisationen immer mehr Services anbieten (und konsumieren), die dank immer stärkerer Digitalisierung immer höhere Sicherheitsanforderungen mit sich bringen. Und effizient ist es erst recht nicht.

Stets zu Diensten

Ein Service ist laut ITIL4 „eine Möglichkeit, gemeinsamen Mehrwert zu schaffen, indem das Erreichen der von Kunden angestrebten Ergebnisse erleichtert wird, ohne dass der Kunde bestimmte Kosten und Risiken managen muss“ (nach Serview ITIL4 Foundation Workbook, Ver. 1.5D) Dabei kommt es nicht darauf an, ob ein Service in der eigenen Organisation erbracht oder ganz oder teilweise zugekauft wird. Immer stellt sich die Frage: Wie schafft man es während des ganzen Lebenszyklus von der Einführung bis zur Stilllegung zu gewährleisten, dass der Service verlässlich die Erwartungen erfüllt und dabei lediglich einen angemessenen Aufwand verursacht?

Offensichtlich müssen hier drei Gesichtspunkte in Einklang gebracht werden – und es sind genau diese drei Gesichtspunkte, die auch im Zentrum des Service-Managements stehen:

• jederzeit die Kundenerwartungen kennen, verstehen und erfüllen
• die IT mit klaren Anforderungen in die Lage versetzen, diese Wünsche effizient in technisch angemessener Weise zu realisieren
• eine kommerzielle Abwicklung des Service gewährleisten, die sowohl dem Kunden einen Mehrwert als auch dem Anbieter eine Erreichung seiner Kosten- beziehungsweise Gewinnziele ermöglicht

Dies lässt sich erreichen, indem man

• ausgehend von den Kundenbedürfnissen die IT-Produkte in einem Servicekatalog hinsichtlich Zweck, Möglichkeiten und Grenzen, Verantwortlichkeiten und Aufwand transparent strukturiert,
• für die Nutzung der so definierten Services klare Spielregeln zwischen Anbieter und Nachfrager in Form von Rollen und Verantwortlichkeiten, Meldungswegen und SPOCs aufstellt und
• neben allgemeinen Effizienzvorteilen aus diesem klaren Service-Design gegebenenfalls auch die Vorteile der Einbindung externer Shared-Services-Anbieter nutzt – und so zum Beispiel Nachfrageschwankungen besser kompensierbar oder den Bedarf nach Spezialwissen besser erfüllbar macht.

Jeder kämpft allein

Dieses Vorgehen schreit praktisch danach, Security-Anforderungen, wie ITIL es vorsieht, als eine Kategorie von Qualitätseigenschaften der Services mit zu behandeln (neben Availability, Continuity, Capacity und ggf. weiteren) – und doch geschieht das in der Praxis noch viel zu selten. CISO/ISB sind also nicht involviert ins Service-Design – und das Service-Management kann seinerseits häufig die notwendigen IT Sicherheitsmaßnahmen nicht beurteilen.

Solange diese Trennung von Sicherheit und Service-Management fortbesteht, finden im Prinzip zwei getrennte Kämpfe gegen dieselben Windmühlen statt. In Kombination mit fehlendem Business-Know-how auf beiden Seiten führt das dazu, dass die Ziele einerseits noch nicht aufeinander abgestimmt sind und andererseits Business-Anforderungen immer wieder individuell abgeholt werden müssen. Das ist für alle Beteiligten dauerhaft aufwendig und zermürbend.

Es fehlt also an einer Vorgehensweise, um die Security systematisch, ganzheitlich und dauerhaft in die Serviceerbringung des gesamten Portfolios einfließen zu lassen.

Ein Beispiel für eine typische Herausforderung eines ISB ist das Thema Pentest: Idealerweise jährlich durchgeführt, kann ein Penetrationstest helfen, das Sicherheitsniveau von Anwendungen oder Infrastrukturen dauerhaft zu heben. Dies funktioniert allerdings nicht, wenn sich – wie in der Praxis häufig der Fall – ein Großteil der gefundenen Schwachstellen immer wieder auf ein systematisches Problem zurückführen lässt, etwa ein mangelhaftes Patch-Management. Das kann besonders dann der Fall sein, wenn die Durchführung von Patches mit anderen Zielen der Serviceerbringung (wie Verfügbarkeit und Stabilität) kollidieren kann. Wenn der Pentest hier das schärfste Schwert der/des ISB ist, kämpft sie/er auf verlorenem Posten.

Grundsätzlich gilt: Immer dann, wenn man Security erst (zu) spät im „Design“ thematisiert oder erst später „andockt“, wird am Ende die Serviceerbringung kostenintensiv oder risikoreich oder beides.

Verankerung in der Serviceerbringung

Anders herum wäre es hilfreich, Security als Kosten- und Nutzenfaktor durch das Service-Management sicht- und messbar zu machen, um die Kosten optimieren und den konkreten Nutzen für das Business herausstellen zu können. Dafür ist ein „Shift Left“ über den Bereich der Softwareentwicklung hinaus notwendig, wo das Konzept bereits einen gewissen Rückhalt hat – bis in das Service-Design und den Betrieb. Security muss also von Anfang an in der Diskussion mit dem Kunden oder besser noch dem Markt mitgedacht und besprochen werden. Das verlangt nach einem intensiven Abgleich mit dem Business, um das richtige Maß an Sicherheit für jeden Service über den gesamten Lebenszyklus aufbauen und aufrechterhalten zu können.

So werden Risikobasiertheit, Wirtschaftlichkeit und Nachhaltigkeit zu (aggregierten) Qualitätskategorien, über die man mit Kunden verhandeln und nicht zuletzt auch Preisfindung betreiben kann. Das gelingt aber nur durch tiefe Integration in andere Qualitätsprozesse und die eingesetzten Service-Management-Frameworks. Am Beispiel der Wirtschaftlichkeit kann das unter anderem bedeuten, keine hochsicheren (und teuren) Services für alle zu bauen, sondern angepasst an das Maß des vom Kunden benannten Risikos.

Ist die Zusammenarbeit erfolgreich, ergeben sich für CISO/ISB eine höhere Sicherheit, das gewünschte Risikoniveau im dauerhaften Betrieb gewährleisten zu können, sowie reduzierter Stress durch weniger „Feuerwehreinsätze“ und eindeutige Verantwortlichkeiten. Aufseiten des Service-Managements lässt sich eine erhöhte Kundenzufriedenheit erzielen sowie möglicherweise sogar ein Alleinstellungsmerkmal auf dem Markt, solange andere die Security noch nachgelagert betrachten und weniger explizit ausweisen.

Das neue Dream-Team

Wenn es also gelingt, die Ziele von CISO/ISB und Service-Management aufeinander abzustimmen, kann es gelingen, eine Kette von Sicherheitsanforderungen vom Kunden des IT-Services bis hin zu den Services selbst abzubilden, die in den einzelnen IT-Abteilungen erbracht werden.

Kunden/Anwender müssen dafür die Frage beantworten (lernen), welche Anforderungen an Vertraulichkeit, Integrität, Verfügbarkeit und gegebenenfalls weitere Werte der im Service verarbeiteten Informationen zu stellen sind und vor allem, was ein Schutzniveau von „sehr hoch“, „hoch“ oder „normal“ an konkreten Maßnahmen in der Serviceerbringung bedeuten soll – dann lässt sich ein entsprechender Schutzbedarf, ähnlich den üblichen Verfügbarkeitsanforderungen, sogar gleich im Service-Level-Agreement (SLA) definieren.

Das Service-Modell muss dafür das Wissen bereitstellen, welche Bereiche innerhalb der IT an der Leistungserbringung eines jeden Services beteiligt sind. Die Bereiche definieren mit Unterstützung durch CISO/ISB die Maßnahmen ihres Teilbereichs (Servicekomponente), um das jeweilige Sicherheitslevel gewährleisten zu können. Der Service-Manager stellt dann – ebenfalls mit Unterstützung durch CISO/ISB – sicher, dass das benötigte Sicherheitsniveau auch im Zusammenspiel der unterschiedlichen Service-Komponenten eingehalten wird.

Herausforderungen

Werden bei der Ausgestaltung des IT-Managements die Services definiert, geht es vor allem darum, Aufgaben, Verantwortlichkeiten, Erwartungen, Leistungserfüllung und das Vorgehen bei Mängeln in der Serviceerbringung zu definieren. Dabei ist eine Vielzahl beteiligter Einheiten mit unterschiedlichsten fachlichen Qualifikationen zu koordinieren. Dennoch bewegt man sich in einem gewissen Maße auf vertrautem Terrain: Man formuliert Erwartungen und sucht gemeinsam nach Lösungsmöglichkeiten. Das führt manchmal sofort zu Ergebnissen, manchmal aber auch erst nach kontroversen Diskussionen, Tests und Anpassungen. In diesem Prozess werden jedoch üblicherweise nur wenige Gedanken an einen möglichen Missbrauch von Systemen und Anwendungen verschwendet.

Das sieht beim Streben nach Sicherheit ganz anders aus: Hier gilt es, das Unbekannte und Unerwartete zu denken. Man muss implizit oder explizit Hypothesen formulieren, wie sich ein Prozess missbräuchlich verwenden lässt. Dabei sind zum einen die Phasen „bei Einführung“ sowie „im Betrieb“ und zum anderen verschiedene interne wie externe Quellen für eine Bedrohung zu unterscheiden. Betrachtet man diese Einteilung, so legen ISB-Aspekte bislang traditionell ihren Schwerpunkt auf den Schutz vor externen Bedrohungen während des Betriebs („untenrechts“ in der Matrix) – dieser wird durch eine Vielzahl von Maßnahmen angestrebt.

Die Sichtweise des Service-Designs ist eine andere: Angestrebt wird die verlässliche Verfügbarkeit des Services während seines gesamten Lebenszyklus – alle Beteiligten und Stakeholder dabei zu berücksichtigen ist eine Selbstverständlichkeit, egal ob sie innerhalb oder außerhalb der Organisation angesiedelt sind. Auch dabei steht die Betriebsphase im Vordergrund, aber Aspekte der Einführungsphase, zum Beispiel Entwicklungsfragen, spielen auch eine Rolle. Entscheidend ist jedoch, dass Sicherheitsfragen klassischerweise beim Service-Design nicht von größtem Interesse sind. Zwar sind beispielsweise Regelungen zu Zugangsberechtigungen fester Bestandteil jedes Service-Designs – das erwähnte Vordenken des „Unbekannten und Unerwarteten“ findet aber meist nicht statt.

Um das zu ändern, muss das Service-Design explizit auch Sicherheitsfragen berücksichtigen, dabei sowohl Bedrohungen von außerhalb der Organisation als auch die oft gefährlicheren internen Risiken beachten und sich vor allem in einer frühen Phase der Einführung und Entwicklung einbringen. Zusammenfassend gesprochen: Das Service-Management muss alle vier Quadranten der von den Phasen und Bedrohungsquellen aufgespannten Matrix betrachten.

Einige Beispiele:

• Man kann bereits beim Anforderungsmanagement den Blick auf Missbrauchsmöglichkeiten im späteren Betrieb richten und von vornherein bei der Entwicklung berücksichtigen (oberer linker Quadrant der Matrix = „interne Bedrohung bei Einführung“).
• In die gleiche Richtung geht die Begleitung der Realisierung: Um an dieser Stelle Sicherheitsfragen angemessen einzubringen, könnte der Anforderer bereits bei Entwicklertests als Gast anwesend sein oder zumindest informiert werden, um frühzeitig sicherheitsrelevante Fehlinterpretationen der Entwicklung und/oder Lücken im eigenen Konzept entdecken zu können.
• Obsolete Services können ein Sicherheitsrisiko darstellen – ein rechtzeitiges Phase-out kann das Service-Design zum Beispiel durch die Einplanung regelmäßiger Audits sicherstellen. Angesprochen sind bei diesem Thema die beiden unteren Quadranten der Matrix.
• Auch bei den klassischen CISO/ISB-Themen im oberen rechten Quadranten hat Service-Design etwas beizutragen: So bietet etwa die Minimierung verwendeter Applikationen die Möglichkeit, die Anzahl potenziell riskanter Schnittstellen zu verringern – ein konkretes Beispiel hierfür sind die komplexen Systeme für Vertriebs- und Servicegesellschaften und ihre Schnittstellen zur Systemlandschaft der Konzernzentrale.

Fazit

Der von den Autoren für die ganzheitliche Herangehensweise gewählte Begriff „Security by Service-Design“ (SxSD) umfasst zunächst eine klare Hierarchie: Das Primärziel ist, Potenzial für Sicherheitsverbesserungen über die heute erreichten Grenzen hinaus zu eröffnen – das Mittel dazu ist das Service-Design oder, umfassender gedacht, das Service-Management.

Will man diesen Weg gehen, stellt sich die Frage, welche Treiber für das Sicherheitsniveau der Beeinflussung durch das Service-Management zugänglich sind.

Versteht man unter Sicherheit ganzheitlich das Verhindern von (versehentlichem oder absichtlichem) Missbrauch, geht SxSD deutlich über das heute übliche Sicherheits-Verständnis hinaus, weil es den gesamten Lebenszyklus eines Services abdeckt und jegliche Form von Fehlverhalten betrachtet. Und genau aus dieser Verbreiterung der Sichtweise resultiert auch das Potenzial für eine erhöhte Sicherheit durch Service-Design: Dank SxSD kann man mithilfe des im Service-Management kanalisierten Business-Know-hows („wo?“) gemeinsam mit der technischen Expertise der Security („wie?“) Bedrohungen deutlich besser abwehren.

Eine Voraussetzung für einen erfolgreichen Einsatz von „Security by Service-Design“ ist selbstverständlich ein gewisser Reifegrad der IT in einer Organisation im Allgemeinen und allem voran eine Vertrautheit mit Elementen des IT-Managements – wie klaren Serviceprozessen, wohldefinierten Rollen und Verantwortlichkeiten – sowie auch ein etabliertes Releasemanagement. Allerdings kann auch die Security hier unter Umständen als Treiberin auftreten, um derartige Prozesse in einer Organisation einzuführen, zu verbreiten oder zu vertiefen.

Andreas Dassen, Martin Glaser und David Fuhr sind Berater der HiSolutions AG im Bereich IT Management.