Praxisorientiertes IT-Risikomanagement E-Book

Matthias Knoll

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2019

Seitenzahl: 541

Beschreibung

IT wird immer öfter zum Enabler für neue Geschäftsmodelle. Diese Entwicklung eröffnet einerseits eine Vielzahl neuer Chancen, bringt andererseits aber auch neuartige Risiken mit sich, da die Abhängigkeit von der IT steigt und die Komplexität zunimmt. Damit Chancen optimal genutzt werden können, ist ein integriertes IT-Risikomanagement notwendig. Es führt alle Fachdisziplinen, die bereits Risiken im IT-Kontext betrachten und behandeln, für eine bestmögliche Risikobeherrschung mit der IT zusammen. Das Buch beschreibt praxisorientiert und systematisch die Grundlagen sowie Organisationsstrukturen und Elemente des IT-Risikomanagementprozesses. Dabei werden gängige Methoden und Dokumente sowie der Einsatz von Werkzeugen anhand von zahlreichen Beispielen aus der Praxis erläutert. Ein Schwerpunkt liegt auf der schrittweisen Einführung und konsequenten Umsetzung des IT-Risikomanagements in IT-Projekten und im Betrieb in allen Organisationen, gleich welcher Größenordnung. Darüber hinaus gibt der Autor Antworten auf aktuelle Fragen zum Umgang mit Risiken aus Virtualisierung, Cloud Computing oder dem Einsatz von Geräten für das Internet der Dinge. Handlungsempfehlungen, Praxishinweise, Checklisten und Vorlagen geben Anregungen, wie IT-Risikomanagement operativ umgesetzt werden kann. Der Anhang des Buches enthält u.a. eine Übersicht über Normen, Standards und weitere Vorgaben für das IT-Risikomanagement sowie ein Glossar. Die 2. Auflage wurde komplett überarbeitet und um Themen wie DevOps/DevSec, Schatten-IT, Industrie 4.0 und datenbasierte Geschäftsmodelle erweitert.

Leseprobe

Prof. Dr. Matthias Knoll, CISA, ist Professor für Betriebswirtschaftslehre an der Hochschule Darmstadt. Sein Spezialgebiet ist die betriebliche Informationsverarbeitung mit den Schwerpunkten GRC-Management, IT-Prüfung und IT-Controlling.

Er studierte an der Universität Stuttgart technisch orientierte Betriebswirtschaftslehre mit den Schwerpunkten Organisation, Wirtschaftsinformatik und Nachrichtentechnik. Im Jahr 2000 promovierte er über die Fragestellung der Abbildung und Steuerung organisationsübergreifender Geschäftsprozesse mit objektorientierten CSCW-Systemen. Es folgte bis zur Berufung an die Hochschule Darmstadt eine sechsjährige Tätigkeit im BI-Umfeld in der IT-Abteilung eines großen Finanzdienstleisters in Baden-Württemberg.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Matthias Knoll

PraxisorientiertesIT-Risikomanagement

Konzeption, Implementierung und Überprüfung

2., überarbeitete und erweiterte Auflage

Prof. Dr. Matthias Knoll

[email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Fachliche Beratung und Herausgabe von dpunkt.büchern im Bereich Wirtschaftsinformatik:Prof. Dr. Heidi Heilmann · [email protected]

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print    978-3-86490-655-8

PDF      978-3-96088-742-3

ePub    978-3-96088-743-0

mobi    978-3-96088-744-7

2., überarbeitete und erweiterte Auflage

Copyright © 2019 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort zur zweiten Auflage

Seit der ersten Auflage sind etwa fünf Jahre vergangen. In der IT ist das eine sehr lange Zeit. Entsprechend viel ist passiert. Mittlerweile gilt es als allgemein akzeptiert, dass sich durch die damals bereits beginnende digitale Transformation alle Unternehmen, aber auch unser Alltag »deutlich« verändern. Es ist notwendig, diese Veränderungen exakter zu beschreiben und zu klassifizieren, um ihre tatsächlichen Auswirkungen besser verstehen zu können. Fragen der Informations-, IT- und nicht zuletzt speziell der Cybersicherheit rücken dabei angesichts unterschiedlichster Ereignisse im Kontext des IT-Einsatzes mehr und mehr ins Bewusstsein der Öffentlichkeit.

Entsprechend hat die Bedeutung des IT-Risikomanagements als ein wichtiges Werkzeug innerhalb eines unternehmensweiten Risikomanagements erheblich zugenommen. Mehr und mehr stellt sich heraus, dass die deutliche Zunahme der technischen Komplexität eingesetzter Lösungen und die damit verbundene steigende fachliche Komplexität in Planung und Betrieb dazu führt, dass eine intensive Diskussion grundsätzlicher Fragen in den Vordergrund tritt. IT-Risikomanagement muss, wie das Risikomanagement in anderen Bereichen auch, institutionalisiert und die Verantwortung dafür ganzheitlich auf Unternehmensleitungsebene gesehen werden. Die Verantwortung für Risiken wandert zunehmend »nach vorne« bzw. »nach oben«. Es ist heute nicht zuletzt vor dem Hintergrund von Compliance- und Haftungsfragen für die Unternehmensleitung entscheidend, hinsichtlich zentraler Prozesse im Internen Kontrollsystem sowie in Bezug auf Sicherheit, Risiko und Business Continuity die Weichen richtig zu stellen und dafür zu sorgen, dass im Falle von eintretenden Risiken »richtig« im Sinne der Compliance-Anforderungen reagiert wird. Geschieht dies nicht, steht schnell der Vorwurf des Organisationsversagens mit allen Konsequenzen im Raum.

Zahlreiche Gespräche, Beobachtungen und Projektbegleitungen in den letzten fünf Jahren zeigen, dass große, insbesondere kapitalmarktorientierte und publizitätspflichtige Unternehmen diese Fragen bereits adressiert und vielfach (weitgehend) gelöst haben. Doch noch immer gibt es insbesondere im Mittelstand Lücken, deren Ursachen häufig in fehlender Personalkapazität und mangelnder Qualifikation liegen. Selbstverständlichkeiten aus dem IT-Risikomanagement sind dann nicht oder nur unvollständig umgesetzt. Sätze wie »Wer interessiert sich schon für uns« oder »Bei uns ist nichts zu holen« fallen immer noch. Gleichzeitig schließen mittelständische Unternehmen mit innovativen digitalen Lösungen zum internationalen Wettbewerb auf oder führen ihn sogar an. Der umfassende Einsatz neuester Informationstechnologie (die früher vielfach »den Großen« vorbehalten war) lässt dabei die Entwicklung für diese Unternehmen besonders gefährlich werden. Denn beispielsweise eine Beurteilung, ob aus neuartigen Angriffsformen, wie den sogenannten »RAMBleed-Attacken«, tatsächlich Risiken für das Unternehmen entstehen können (»Was hat das mit meiner Cloud-Lösung zu tun?«), erfordert Awareness und methodisches Vorgehen. Gleiches gilt ggf. für die zu ergreifenden Gegenmaßnahmen.

Die vorliegende zweite Auflage trägt diesem Umstand auf unterschiedliche Weise Rechnung. Zum einen sind einzelne Aspekte, etwa der Einsatz von Geräten für das Internet der Dinge, oder neue Paradigmen, wie DevOps, ergänzt, andere, wie etwa Normen und Standards, aktualisiert sowie Zusammenhänge in der Theorie präzisiert worden. Zum anderen sind neue Aspekte aufgenommen worden, die mit Blick auf kritische Infrastrukturen oder Fragen der IT-Strategie, IT-Governance und IT-Architektur eine bisher bestehende Lücke schließen.

Zielgruppe

Dieses Buch richtet sich an alle Neu- und Quereinsteiger in das Themengebiet sowie an Studierende, die sich mit der vielschichtigen und vielseitigen Materie näher befassen wollen oder im Rahmen von Veranstaltungen müssen.

Praxisbeispiele und Handlungsempfehlungen sollen eine Orientierung und Vorschläge für eigene Gedanken ermöglichen. Naturgemäß können solche allgemein gehaltenen Hinweise niemals so speziell sein, dass erfahrene Risikomanager sie als Vorbild (Blaupause) direkt nutzen könnten. Für ein solches Vorbild wäre meines Erachtens sowohl Kenntnis über die jeweilige Branche als auch – in besonderem Maße – möglichst detailliertes Wissen über die unternehmensinternen Prozesse und Rahmenbedingungen notwendig.

Dennoch hoffe ich, dass auch Experten von diesem Buch profitieren können – einerseits durch Übersichten zu den aktuellen Normen und Standards, andererseits durch Bündelung von Themen und Hinweisen auf weiterführende Informationsquellen. Ein Abgleich mit dem eigenen Wissen ist auf diesem Weg ebenso möglich wie weiter gehende Überlegungen zum Einsatz von Methoden und Werkzeugen für das Risikomanagement anhand der im Buch enthaltenen Übersichten und Hinweise.

Das Buch berücksichtigt neben wissenschaftlichen Quellen auch Beiträge aus der Praxis. Es ist, wie der Titel sagt, praxisorientiert und will nicht den Anspruch einer forschungsorientierten, wissenschaftlichen Auseinandersetzung mit dem Thema erheben. Ziel ist es, dabei zu helfen, das Risikomanagement in der Praxis einzuführen, wo dies noch nicht geschehen ist, und dabei zu unterstützen, es zu verbessern, wo es bereits etabliert ist.

Dabei ist eine Trennung zwischen IT-Risikomanagement und IT-Sicherheit nicht immer einfach. Viele Fragen aus der IT- und speziell der Cybersicherheit haben große Schnittmengen mit dem IT-Risikomanagement. Auch wenn es verlockend ist und interessant wäre, auf Einzelheiten näher einzugehen, etwa bei den speziellen Risiken, aber auch bei den Maßnahmen zur Behandlung dieser Risiken, verzichtet der Text bewusst darauf, verweist jedoch an zahlreichen Stellen auf bestehende Schnittmengen, Normen, Standards und Informationsquellen.

Dank

Auch an der zweiten Auflage dieses Buches haben viele Hände mitgewirkt.

Besonders danken möchte ich meinem Kollegen Daniel Burda, der das Manuskript bereits vorab kritisch durchgesehen und zahlreiche wichtige Impulse zur Verbesserung eingebracht hat, und ebenso den Gutachtern, die viele weitere wertvolle Hinweise im Rahmen des sich anschließenden Reviewprozesses beigesteuert haben und so ebenfalls ihren Beitrag dazu geleistet haben, den Text weiter zu verbessern.

Mein Dank gilt auch meinem Kollegen Urs Andelfinger und Frau Nadin Ebel, die mich mit Informationen zu Standards versorgt und dadurch mitgeholfen haben, Sachverhalte zu präzisieren und Darstellungsfehler zu vermeiden. Irrtümer, die nun noch im Text zurückgeblieben sind, habe ich daher vollständig selbst zu verantworten.

Beim Lektorat und Copy Editing, insbesondere bei Christa Preisendanz und Ursula Zimpfer, sowie bei allen Mitarbeiterinnen und Mitarbeitern des dpunkt.verlags, die in den Herstellungsprozess eingebunden waren, möchte ich mich für die motivierende Betreuung und sehr geduldige Begleitung und die gewohnt höchste Qualität von Satz und Druck ganz herzlich bedanken. Es freut mich sehr, dass das Buch auch in zweiter Auflage im dpunkt.verlag erscheinen darf.

Ich hoffe, dass auch diese zweite Auflage viele interessante und vor allem neue Impulse für Ihre tägliche Arbeit enthält und natürlich wie bereits vor fünf Jahren, dass Sie darin Bewährtes bestätigt finden. Ich freue mich über Ihr Lob ebenso wie über Ihre Anregungen und Kritik, denn nichts ist perfekt und manches regt sicherlich zu Diskussionen an.

Matthias KnollDarmstadt im Juni 2019

Vorwort zur ersten Auflage

Die steigende Abhängigkeit aller Unternehmen von der IT, die zunehmende globale Vernetzung, innovative IT- und internetbasierte Geschäftsmodelle, aber auch neue Endgeräte eröffnen nicht nur vielfältige Chancen. Sie erfordern auch eine sorgfältige Beschäftigung mit ebenso vielfältigen neuen Risiken. Schließlich möchte kein Unternehmen sensible Daten offenlegen, mit Störungen in den Betriebsabläufen konfrontiert werden oder in der Öffentlichkeit negativ auffallen. Presseberichte, Studien und Konferenzbeiträge bestätigen diese Notwendigkeit. Sie verweisen auf eine wachsende Zahl einschlägiger Vorfälle und die hohe »Professionalität« derjenigen, die für gezielte, immer gefährlichere Angriffe und den Diebstahl vertraulicher Daten verantwortlich sind.

Erfahrene IT-Risikomanager wissen, dass sich solche Vorfälle in jeder Branche ereignen und Unternehmen aller Größen treffen können. Es ist nicht die Frage, ob, sondern nur, wann etwas geschieht und wie groß der Schaden ist. Vorkehrungen müssen also getroffen werden, und selbst das ist weder einfach noch eine Erfolgsgarantie. Immer wieder stellen Experten fest, dass neue Schwachstellen entstanden sind, ehe alte beseitigt werden konnten, und ergriffene Maßnahmen wirkungslos werden, ehe bessere einsatzbereit sind. Der Umgang mit Risiken, das IT-Risikomanagement, ist deshalb ein ständiger Prozess.

Es gibt unterschiedliche Möglichkeiten, diese Aufgaben zu bewältigen. Um die Grundlagen zu vermitteln, die Theorie darzustellen und beides mit Erfahrungen aus der Praxis anzureichern, ist dieses Buch entstanden. Interviewpartner aus Unternehmen unterschiedlicher Größe haben den Blick aus Forschung und Lehre um die Erfahrung derjenigen ergänzt, die IT-Risikomanagement täglich betreiben, immer in dem Bestreben, Risiken von ihrer IT fernzuhalten. Alle Sachverhalte, Abkürzungen und Strukturen in den Beispielen wurden gezielt verfremdet. Ähnlichkeiten mit Verhältnissen in bestimmten Unternehmen wären rein zufällig und nicht beabsichtigt.

In einem einzelnen Buch können niemals alle Facetten ausführlich diskutiert werden. Es wird immer Aspekte geben, die unberücksichtigt bleiben müssen. Diesen Anspruch erhebt das vorliegende Buch deshalb nicht. Vielmehr soll diese Kombination aus Theorie und Praxis denjenigen Lesern Hilfestellung geben, die sich in diesem Themengebiet neu orientieren. Für diejenigen Leser, die bereits im IT-Risikomanagement tätig sind, aber das Gefühl haben, nicht genug zu tun oder Wichtiges zu übersehen, kann das vorliegende Buch vielleicht den einen oder anderen neuen Impuls geben. Und nicht zuletzt richtet sich das Buch an alle Lernenden. Es ist zwar kein Lehrbuch, ist jedoch als ergänzende Lektüre einsetzbar.

Dank

Ein solches Buch entsteht durch vieler Hände Arbeit.

Bedanken möchte ich mich ganz besonders bei allen Interviewpartnern. Sie haben sich umfassend Zeit genommen und mir das Vertrauen geschenkt, das ein offenes Gespräch über ein solch sensibles Thema erfordert. Mein besonderer Dank gilt auch Dr. Markus Böhm, PwC Frankfurt, der trotz seiner Verpflichtungen den gesamten Text sehr kritisch durchgesehen, Praxisbeispiele und Handlungsempfehlungen ergänzt und geschärft und insbesondere die Kapitel 10 und 11 wesentlich gestaltet hat. Meinem Kollegen Prof. Dr. Stefan Ruf, Hochschule Albstadt-Sigmaringen, verdanke ich viele weitere wertvolle Hinweise. Ohne seine Erfahrungen und seine Ideen und Anregungen wäre manches gute Argument unberücksichtigt geblieben. Und schließlich geht ein großer Dank an alle Gutachter für ihre vielen hilfreichen Hinweise zur Verbesserung des Textes.

Beim Lektorat, insbesondere bei Vanessa Niethammer, dem Copy Editing und allen Mitarbeiterinnen und Mitarbeitern des dpunkt.verlags möchte ich mich für die motivierende Betreuung und sehr geduldige Begleitung des Entstehungsprozesses und die gewohnt hohe Qualität von Satz und Druck ganz herzlich bedanken.

Mein besonderer Dank gilt schließlich der Herausgeberin dieses Buches, Frau Prof. Dr. Heidi Heilmann, die durch ihre konstruktiven Hinweise den Text hat besser werden lassen und mir während des gesamten Erstellungsprozesses mit fachlichem und menschlichem Rat zur Seite stand.

Ich hoffe, dass Sie viel Freude bei der Lektüre dieses Buches haben und natürlich, dass Sie Neues kennenlernen oder Bewährtes bestätigt finden. Ich freue mich über Ihr Lob ebenso wie über Ihre Anregungen und Kritik, denn nichts ist perfekt, und manches regt sicherlich zu Diskussionen an.

Matthias KnollDarmstadt im Dezember 2013

Inhaltsübersicht

1Einführung

2Der Begriff Risiko

3Grundlagen des Risikomanagements

4Aufbauorganisation

5Risiken beherrschen

6Methoden, Werkzeuge und Dokumente

7Strategische Risiken

8IT-Betriebsrisiken

9IT-Projektrisiken

10Risikomanagement im Unternehmen einführen

11Das Interne Kontrollsystem

12Das Risikomanagementsystem prüfen

13Wie könnte es weitergehen?

Anhang

AÜbersicht über Normen, Standards und weitere Vorgaben für das IT-Risikomanagement

BGlossar

CAbkürzungsverzeichnis

DReferenzen

Stichwortverzeichnis

Inhaltsverzeichnis

1Einführung

2Der Begriff Risiko

2.1Der Risikobegriff

2.1.1Bedrohungen in der IT

2.1.2Schwachstellen in der IT

2.1.3Schutzziele

2.1.4Risikopotenzial

2.1.5Der Wahrscheinlichkeitsbegriff und das Risiko

2.1.6Risikoarten

2.1.7Systematisierung von Risiken

2.1.8Klassifikation von Risiken

2.1.9Die Darstellung von Risiken in der Praxis

2.1.10Ursache-Wirkungs-Beziehungen in der IT

2.1.11IT und der Faktor Zeit

2.2Risikopolitik

2.2.1Das Risikobewusstsein

2.2.2Die Risikokultur

2.2.3Risikoappetit und Risikoneigung

2.2.4Risikoakzeptanz, Risikotoleranz und Risikotragfähigkeit

2.2.5Risikorichtlinie

3Grundlagen des Risikomanagements

3.1Begriff und Ausprägungen des Risikomanagements

3.1.1Risikomanagement

3.1.2Enterprise Risk Management

3.2Das IT-Risikomanagement

3.2.1Anforderungen an das IT-Risikomanagement

3.2.2Risikostrategien

3.3Normen, Standards und weitere Vorgaben

4Aufbauorganisation

4.1Wahl der Organisationsstruktur

4.2Rollen

4.3Gremien

4.4Externe Gruppen

4.5Qualifikationsaspekte

5Risiken beherrschen

5.1Grundstruktur und organisatorische Verankerung

5.2Zuordnung von Verantwortung

5.3Schritt 1: Definition des Kontexts

5.4Schritt 2: Identifikation

5.5Schritt 3: Analyse

5.6Schritt 4: Bewertung

5.7Schritt 5: Behandlung

5.8Reporting, Kommunikation und Beratung

5.9Risikocontrolling

6Methoden, Werkzeuge und Dokumente

6.1Methoden und Werkzeuge

6.2Dokumente

6.3Hilfestellungen für die Auswahl

6.4Softwareunterstützung

7Strategische Risiken

7.1IT-Strategie

7.2IT-GRC-Management

7.3IT-Architektur

7.4Digitale Geschäftsmodelle und smarte Produkte

8IT-Betriebsrisiken

8.1Organisation des IT-Betriebs

8.1.1Zentraler und dezentraler Betrieb

8.1.2Outsourcing und Outtasking

8.1.3Cloud Computing

8.1.4Virtualisierung

8.1.5Schatten-IT

8.2Unzulänglichkeiten, Fehler und Ausfälle

8.2.1Ursache »Personen und Organisationseinheiten«

8.2.2Ursache »Daten«

8.2.3Ursache »Anwendungen und IT-Infrastruktur«

8.2.4Ursache »IT-Prozesse und IT-Organisation«

8.2.5Ursache »IT-Umfeld«

8.3Angriffe

8.4Notfälle und Katastrophen

8.5Internet der Dinge und Industrie 4.0

8.6Nutzung von Mobilgeräten

8.7IT-Betrieb in kleinen Unternehmen

9IT-Projektrisiken

9.1Risiken in IT-Projekten

9.2DevOps und DevSec

9.3Open-Source-Projekte

10Risikomanagement im Unternehmen einführen

10.1Schritte zur Entwicklung und Einführung

10.2Wirtschaftlichkeitsbetrachtungen

11Das Interne Kontrollsystem

11.1Begriff

11.2Aufbau

11.3Der Begriff »Kontrolle«

11.4Das Three-Lines-of-Defense-Modell

11.5Konzeption des Internen Kontrollsystems

12Das Risikomanagementsystem prüfen

12.1Formen und Varianten der Prüfung

12.2Prüfungsablauf

13Wie könnte es weitergehen?

Anhang

AÜbersicht über Normen, Standards und weitere Vorgaben für das IT-Risikomanagement

BGlossar

CAbkürzungsverzeichnis

DReferenzen

Stichwortverzeichnis

1Einführung

Die digitale Transformation

Waren bis vor wenigen Jahren noch Kostenreduzierung und Standardisierung sowie die Steuerung externer Dienstleister zentrale Herausforderungen an die Unternehmens-IT, dominieren heute Fragen der IT- und spezieller der Cybersicherheit, die Komplexitätsreduktion durch »passende« Unternehmensarchitekturen, Daten als »Vierter Produktionsfaktor«, der Plattformgedanke, Virtualisierung und Cloud sowie eine unbedingte 24/7-Verfügbarkeit zur Unterstützung neuer Geschäftsmodelle die Diskussion. Davon betroffen sind nicht nur Unternehmen, sondern Organisationen jeder Art. Alle öffentlichen (staatlichen und nicht staatlichen) Einrichtungen werden daher ebenso in die folgenden Überlegungen einbezogen wie gemeinnützige und alle sonstigen in der Öffentlichkeit sichtbaren Organisationen, auch wenn einheitlich der Begriff »Unternehmen« verwendet wird.

Denn die IT verändert jedes Unternehmen durch einen Prozess, der – auf Basis des technischen Fortschritts und einer immer besseren, auch mobilen Vernetzung – erst begonnen hat und noch lange nicht abgeschlossen ist und den wir als »digitale Transformation« wahrnehmen. Diese digitale Transformation führt dazu, dass bekannte und bewährte Produkte auf anderen Wegen vertrieben werden und/oder anders »funktionieren«. Sie hat aber auch zur Folge, dass viele neuartige Produkte und Dienstleistungen entstehen und sich die Zusammenarbeit zwischen Unternehmen wesentlich verändert. Als Beispiele für diese Entwicklungen dienen neuartige Mobilitätsdienste (etwa Uber) und Übernachtungs-/Urlaubsangebote (bspw. AirBnB), Streamingdienste, die das lineare Fernseh- und Rundfunkprogramm ablösen (etwa Netflix, Spotify), oder Unternehmen sowohl im B2B- als auch im Endkundenbereich, die nicht mehr ausschließlich ihre Produkte mit traditionell verstandener Wartung vertreiben, sondern vollkommen neuartige Abo-Dienstleistungen auf Basis ihrer Produkte oder in Kombination mit ihren Produkten verkaufen, einschließlich Konzepten der Predictive Maintenance. Die Geschäftsmodelle dieser Unternehmen folgen neuartigen Ansätzen oder verändern teilweise radikal bestehende Strukturen.

Fragen der Informationssicherheit und des Datenschutzes, aber auch weitere Risiken rücken damit zunehmend in den Vordergrund. Es vergeht praktisch kein Tag ohne neue Meldungen über identifizierte Sicherheitsprobleme in Hard- und Software, Datenlecks und einen zu sorglosen Umgang mit sensiblen Daten, aber auch Überlegungen einzelner Regierungen, auf verschiedenste Daten (etwa aus sozialen Medien oder von Smart-Home-Geräten) zugreifen zu können. Bekannte Beispiele sind etwa die Sicherheitslücken in Prozessoren und anderer Hardware großer Hersteller, teilweise politisch aufgeladene Datenschutzskandale, Manipulationen, die schwerpunktmäßig große Social-Media-Anbieter treffen, neue Einreisebestimmungen mit Offenlegungspflichten sowie eine mögliche Gefährdung unseres Alltags durch Cyberattacken auf wichtige Elemente unserer lebensnotwendigen Infrastruktur, etwa der Wasser- und Energieversorgung. Unter diesen Bedingungen IT erfolgreich zu steuern, setzt ein hohes Maß an fachlicher und sozialer Kompetenz, effektiven und effizienten Methoden, Erfahrung und Geschick voraus.

Business-IT-Alignment

Zum Streben nach bestmöglicher IT-Unterstützung aller Geschäftsprozesse, dem bestmöglichen Business-IT-Alignment, kommt die Verpflichtung hinzu, das Unternehmen und seine Eigentümer vor Schaden durch die IT zu bewahren. Denn mit den vielfältigen neuen Herausforderungen gehen zwangsläufig ebenso vielfältige neue Bedrohungen und Schwachstellen einher. Was bedeutet es für uns und unseren Alltag, wenn die IT nicht verfügbar ist? Wenn sie Fehler in den Geschäftsprozessen verursacht, die Missbrauch, Datenmanipulation oder Datenspionage ermöglicht?

Nicht alles lässt sich durch verantwortungsvolle Führung verhindern, wohl aber darf (in besonders sensiblen Bereichen muss) verlangt werden, dass das Unternehmen vorbereitet ist und angemessene Gegenmaßnahmen ergreift. Sich über mögliche Bedrohungen und Schwachstellen sowie geeignete Gegenmaßnahmen zu informieren, ist deshalb eine zentrale Forderung an die IT-Leitungsebenen. Es geht dabei um einen zielorientierten und besonnenen Umgang mit einer künftigen Situation, auf die man sich bereits heute einstellen muss. Das erfordert eine genaue Kenntnis der gegenwärtigen Situation in der IT und im Gesamtunternehmen.

Gegenmaßnahmen kosten Zeit und Geld. Zu schnell kann aus übertriebener Sorge zu viel investiert werden. Dieser Endpunkt im Kontinuum des Aufwandes verbietet sich ebenso wie der Anfangspunkt geringstmöglichen Aufwandes, der auf zu großem Optimismus, Leichtsinn oder – noch schlimmer – Ahnungslosigkeit beruht.

Der Begriff »Wesentlichkeit«

Ziel aller Bemühungen und Überlegungen ist es, in betriebswirtschaftlich vernünftiger Form wesentliche Risiken von der IT und damit stets auch vom Gesamtunternehmen und seinen Geschäftsprozessen fernzuhalten, deutlich zu reduzieren oder ihre Auswirkungen zu begrenzen.

Das Informationssystem

Der Anwendungsbereich dieser Überlegungen (vgl. Abb. 1–1) erstreckt sich auf folgende Punkte:

Personen

und

Organisationseinheiten

, die in irgendeiner Form einen Bezug zu den weiteren Elementen haben. Der Begriff IT-Organisation im Speziellen umfasst dabei neben organisatorischen Regelungen (Ablauforganisation, siehe IT-Prozesse) alle Organisationseinheiten (Aufbauorganisation) mit IT-Bezug. Zur IT-Organisation gehören demzufolge die IT-Abteilung sowie Bereiche und Rollen in den Fachabteilungen mit IT-Bezug.

Daten

bzw.

Informationen

Eingeschlossen sind alle Daten zur Installation, Konfiguration und Administration von Software sowie Dokumente mit IT-Bezug.

Anwendungen

Unter diesem Begriff (engl.: Application oder kurz App) wird nach ISO/IEC 2382:2015 Software zur Unterstützung der unterschiedlichen Geschäftsprozesse zusammengefasst. Anwendungen haben stets einen fachlichen Fokus.

Industrial Automation Applications (IAA)

Diese Art Software wird im Fertigungsbereich zur Unterstützung der Planungs- und Steuerungsprozesse eingesetzt. Im Kontext von Industrie 4.0 und der damit verbundenen zunehmenden Vernetzung dieser Anwendungen untereinander und mit weiteren internen und externen Anwendungen gewinnt diese Gruppe nicht zuletzt aus IT-Sicherheits- und Risikosicht stark an Bedeutung (siehe dazu Normenreihe IEC 62443, NIST SP 800-82 Rev. 2).

Systemsoftware

Dazu zählt nach ISO/IEC 2382:2015 das Betriebssystem und andere für den IT-Betrieb notwendige Software (sog. Middleware), mitunter werden auch Datenbankmanagementsysteme in dieser Ebene eingeordnet, ebenso Spezialsoftware für Appliances und Mobilgeräte (sog. Firmware).

Hardware

Eingeschlossen sind Großrechner ebenso wie Server oder zentrale Speichersysteme (SAN/NAS) und Arbeitsplatzrechner, Bildschirme, Drucker und weitere Peripheriegeräte, aber auch alle mobilen Geräte.

Netzwerk

Hierunter fallen alle Netzwerkgeräte, beispielsweise sogenannte Appliances wie Firewalls, Router sowie alle aktiven und passiven Komponenten zur Datenübertragung.

IT-Prozesse

zur unmittelbaren Unterstützung von

Geschäfts- und Produktionsprozessen

, aber auch von

administrativen IT-Betriebsabläufen

, etwa Datensicherungen oder die Durchsicht von Protokollen.

Geschäfts-/Produktionsprozesse und ergänzende organisatorische Regelungen.

Sie beschreiben die

Logik

aller Produktions- und Geschäftsprozesse und legen

Berechtigungen

und

Verantwortlichkeiten

sowie prozessunabhängige und -übergreifende

Regelungen

fest.

Sonstige, nicht IT-bezogene Ressourcen

als Bestandteile von Geschäfts- und Produktionsprozessen.

Abb. 1–1Informationssystem

Alle Elemente in Abbildung 1–1 zusammen beschreiben ein Informationssystem als soziotechnisches System, in dem der Mensch, die von ihm entwickelten Regelungen bzw. fachlichen/technischen Prozesse, alle Daten sowie die unterstützenden IT-Systeme zusammengefasst sind.

Definition

Die Disziplin, die sich mit Risiken aus Entwicklung, Betrieb und Nutzung solcher Informationssysteme befasst, wird IT-Risikomanagement genannt.

Die fünf grau hinterlegten Elemente beschreiben zusammengenommen ein IT-System. Das IT-System lässt sich nach seiner Unterstützung für betriebswirtschaftliche oder technische Aufgaben entsprechend differenzieren.

Zur Systematisierung von betriebswirtschaftlich genutzten IT-Systemen (etwa ERP-, CRM-, BI- oder E-Commerce-Systeme sowie weitere Systeme mit Endkundenfokus) existieren in der Wirtschaftsinformatik mehrere Ansätze, meist wird nach Anwendungsbereichen oder nach Vernetzungsfähigkeiten mit externen Partnern differenziert. In diese Gruppe fallen auch alle IT-Systeme, die den Plattform-Ansatz unterstützen, etwa Social-Media-, Streaming-, Mobilitäts- und weitere Angebote, die verschiedene Anbieter mit Kunden verbinden. Dazu zählen auch Smartphones und Tablets mit den jeweiligen App-Stores.

Ein IT-System zur Unterstützung technischer Aufgaben wird Steuerungssystem für Industrieanlagen bzw. Industrial Control System (ICS) genannt. In diese Gruppe fallen – als separate Elemente oder als Bestandteil von ICS – auch alle Elemente des sogenannten Internet der Dinge (engl.: Internet of Things, IoT, vgl. Abschnitte 7.4 und 8.5). Neben produktionsunterstützenden Systemen rund um Fertigungs- und Logistikanlagen fallen alle für die Gebäudeautomation/Smart Home eingesetzten Systeme darunter. Die Beispiele reichen dabei von einem Aktor oder Sensor mit Netzwerkanbindung bis hin zu einer vollständigen Lösung zur Steuerung/Überwachung von Gebäuden und Anlagen mit Benutzeroberfläche und Schnittstellen zu betrieblichen Anwendungen. Zu dieser Gruppe gehören spätestens mit der (beinahe) flächendeckenden Einführung von Voice-over-IP-Technologien (VoIP) und der damit einhergehenden Einbindung in das bestehende Netzwerk auch alle Telekommunikationsanlagen und -endgeräte in den Unternehmen, die zuletzt noch vollkommen separat betrachtet wurden.

IT-Systeme wie Smart TVs oder Wearables (etwa Smart Watches) lassen sich meist nicht exakt einordnen, vielmehr liegen sie je nach Anwendungsschwerpunkt entsprechend näher an betriebswirtschaftlichen bzw. endkundenorientierten oder produktions- und steuerungsnahen Anwendungen. So erfüllt beispielsweise ein Smart TV in einem Besprechungsraum eine andere Aufgabe als in der Produktion oder im Privathaushalt.

Das IT-Risikomanagement schließt deshalb neben der betriebswirtschaftlichen Sicht auf die IT auch die Sicht auf Steuerungen und Produktionsanlagen sowie alle weiteren oben beschriebenen Komponenten mit IT-Anteilen (bspw. VoIP-Telefonanlagen) ausdrücklich mit ein. Die IT in diesen Bereichen wird aufgrund des gekapselten und häufig proprietären Charakters der darin enthaltenen Hard- und Software bislang in vielen Unternehmen als Schatten-IT bezeichnet, auch wenn dieser Begriff eher aus dem betriebswirtschaftlichen Kontext (in den Fachabteilungen entwickelte Office-Anwendungen) bekannt ist. Sie untersteht in solchen Fällen nicht der Verantwortung der IT, sondern vielfach noch der Produktionsleitung (Fertigungsanlagen), spezialisiertem Leitstellenpersonal (Steuerungsanlagen, etwa in der Energie-/Wasserversorgung), dem Facility Management (Gebäudeautomation, Telekommunikationsanlagen) oder medizinisch-technischem Fachpersonal in entsprechenden Einrichtungen (medizinisch-technische Geräte). Entsprechend waren und sind solche IT-Systeme vielfach vom IT-Risikomanagement nicht erfasst worden. Das ändert sich aktuell, nicht zuletzt aufgrund zunehmender Sicherheitsvorfälle (etwa Angriffsmöglichkeiten auf Herzschrittmacher, Insulinpumpen und andere Geräte).

Diese Entwicklung ist positiv zu bewerten, denn eine intensive Betrachtung wird zwingend notwendig, weil IT-Systeme, die nicht in die Lebenszyklus-, Service- und Supportprozesse und -strukturen der IT eingebunden sind, zunehmend eine Bedrohung für das einsetzende Unternehmen, aber auch für dessen Kunden werden können. Anlagen und Produkte einschließlich darauf basierender digitaler Dienstleistungen könnten fehlerhaft oder nicht verfügbar sein, mit allen Folgen bis hin zur Gefahr für Leben oder Gesundheit der jeweiligen Nutzer.

Aufbau des Buches und Hinweise zur Nutzung der Praxiselemente

Struktur des Buches

Das Buch gliedert sich in vier größere Themenbereiche (vgl. Abb. 1–2).

Abb. 1–2Thematischer Aufbau des Buches

Der erste Themenbereich (Kap. 2 und 3) legt die begrifflichen Grundlagen. Der zweite Themenbereich (Kap. 4 bis 6) behandelt die Organisation des IT-Risikomanagements, den IT-Risikomanagementprozess sowie Methoden, Werkzeuge und Dokumente des IT-Risikomanagements. Der dritte Themenbereich (Kap. 7 bis 10) betrachtet das IT-Risikomanagement im strategischen Bereich und damit im Kontext des IT-GRC-Managements, dem IT-Betrieb und in IT-Projekten, an der Schnittstelle zwischen Entwicklung und Betrieb sowie die notwendigen Schritte zu seiner Einrichtung. Das Kapitel 8 befasst sich auch mit Fragen des IT-Risikomanagements beim Einsatz von Cloud-Angeboten für Endkunden sowie allen übrigen Dienstleistungen mit IT-Anteil, die den Endkunden direkt einbeziehen. Der vierte Themenbereich (Kap. 11 und 12) stellt das Interne Kontrollsystem und seine Bedeutung für das IT-Risikomanagement dar und erläutert die Prüfung des IT-Risikomanagements hinsichtlich Angemessenheit und Wirksamkeit.

Ein wichtiges Ziel ist es, die Theorie des IT-Risikomanagements für die Praxis aufzubereiten. Dazu hebt das Buch wichtige Definitionen hervor, ergänzt die Theorie durch kleine (Anwendungs-)Beispiele und hilft bei der Umsetzung durch Praxishinweise, konkrete Handlungsempfehlungen und Muster als Anregung für die Erstellung eigener Checklisten.

Ein Praxishinweis ist erkennbar am Hinweis in der Marginalspalte und einem grau unterlegten Kasten.

Praxishinweis

Konkrete Fragestellung

Als Antwort auf die jeweilige Fragestellung sind in einem Praxishinweis wichtige Erfahrungen in knapper Form zusammengefasst.

Handlungsempfehlungen sind gekennzeichnet durch einen Hinweis in der Marginalspalte und eine Schritt-für-Schritt-Empfehlung zur Umsetzung.

Handlungsempfehlung

Schritt-für-Schritt-Empfehlung für die Bearbeitung einer bestimmten Fragestellung

Schritt 1

Handlungsempfehlung

Schritt 2

Inhaltlich nächste Aktivität, ggf. Alternativen, Bedingungen

Checklisten enthalten Punkte, die bei der Beschäftigung mit einer Aufgabe im eigenen Unternehmen sinngemäß Berücksichtigung finden sollten. Sie sind in der Marginalspalte gekennzeichnet und als Tabelle ausgestaltet.

Checkliste

Checkliste zur Aufgabenstellung

1.

Zu beachtender Aspekt, ggf. mit Unterpunkten

Grad der Erfüllung/Abdeckung, Statusinformation

2.

Weitere Frage im Kontext

nicht erfüllt, erfüllt, kann aber noch verbessert werden, erfüllt

Denn beim Auf- und Ausbau des eigenen IT-Risikomanagements gilt grundsätzlich, dass Vorlagen und Überlegungen aus Büchern, Zeitschriften und dem Internet hilfreich sein können. Allerdings ist eine direkte Übernahme von Inhalten erwartungsgemäß selten möglich. Für eine Nutzung sollten – etwa im Rahmen eines Workshops:

Begriffe in die Sprachwelt des Unternehmens übertragen werden;

inhaltliche Details zu Prozessen und der IT auf Übereinstimmung geprüft und angepasst werden – dies betrifft beispielsweise verwendete Systematisierungen, Klassifizierungen, Einheiten, Farbcodes und Symbole;

Besonderheiten des eigenen Unternehmens ergänzt werden. Dabei handelt es sich meist um Spezifika aus der Geschäftstätigkeit, die (in einem Workshop) im Dialog mit den betroffenen Fachabteilungen ermittelt werden müssen. Dies gilt besonders in regulierten Branchen und im KRITIS-Umfeld.

2Der Begriff Risiko

Ziel dieses Kapitels

Dieses Kapitel führt in den Begriff Risiko im Kontext des Lebenszyklus eines Informationssystems (Abb. 1–1) ein. Im Einzelnen werden die folgenden Fragen geklärt:

Was ist ein Risiko, was ist ein IT- und ein Informationssicherheitsrisiko, wie lassen sich solche Risiken systematisieren und klassifizieren?Was sind Cyberrisiken, IT-Sicherheitsrisiken und Informationsrisiken?Warum werden Ursachen und Auswirkungen separat betrachtet?Was sind Bedrohungen und Schwachstellen? Warum wird hier unterschieden?Welche Rolle spielt die Zeit im Kontext von Risiken?Was sind Risikobewusstsein, Risikokultur, Risikoappetit und Risikopolitik?Wie sieht eine Risikorichtlinie aus und wofür wird sie benötigt?

2.1Der Risikobegriff

Die betriebswirtschaftliche Literatur kennt zahlreiche Definitionen und unterschiedliche Auffassungen des Begriffs Risiko (bspw. [Königs 2017], S. 11 f., [Gabler 2019], [RiskNet 2019]). Im ISO Guide 73:2009 und weiteren, speziellen Normen, die Auswirkungen auf die IT haben, etwa beim Einsatz von IT in der Medizintechnik (ISO 14971:2007), wird Risiko als »effect of uncertainty on objectives« bzw. als »the combination of the consequences of an event and the associated likelihood« (oder entsprechend als »combination of the probability of occurrence of harm and the severity of that harm«) definiert. ISO 31000:2018 definiert entsprechend »Risk is usually expressed in terms of risk sources (Abschnitt 3.4 der Norm), potential events (Abschnitt 3.5 der Norm), their consequences (Abschnitt 3.6 der Norm) and their likelihood (Abschnitt 3.7 der Norm).« Unsicherheit entsteht dabei durch fehlende Informationen, mangelndes Verständnis oder fehlendes Wissen.

Auch das BSI definiert in seinem Glossar den Begriff allgemein [BSI 2019]. IDW PS 981 sieht in Risiken mögliche künftige Entwicklungen oder Ereignisse, die zu negativen oder positiven Zielabweichungen führen können [IDW 2017a]. ISACA betont in seiner Definition insbesondere die notwendige Trennung zwischen Risiko, Bedrohung (Abschnitt 2.1.1) und Schwachstelle (Abschnitt 2.1.2). Risiken beziehen sich demnach auf »the likelihood (or frequency) and magnitude of loss that exists from a combination of asset(s), threat(s) and control conditions« [ISACA 2019].

Ein gemeinsames Element in allen Definitionen ist die unternehmensspezifisch mehr oder weniger stark ausgeprägte Unfähigkeit, das zu steuern, was in Zukunft eintreten wird. Entsprechend lassen sich die Definitionen folgendermaßen zusammenfassen:

Definition

Das Risiko

Das Risiko ist ein Maß für Wagnis und Unsicherheit. Es beschreibt die Möglichkeit, als Konsequenz eines bestimmten Verhaltens oder Geschehens durch ein (plötzlich auftretendes) zukünftiges ungewisses Ereignis einen (monetären) Gewinn oder Nutzen (Chance) zu erzielen oder aber einen (monetären) Schaden (Verlust, Misserfolg) zu erleiden bzw. einen erwarteten Vorteil nicht nutzen zu können. Inwieweit im Unternehmen etwas als Schaden oder Nutzen verstanden wird, hängt von den Wertvorstellungen der Risikoverantwortlichen ab.

Möglich sind also positive wie negative Entwicklungen, wenngleich in der (deutschsprachigen) Praxis weniger der Aspekt »Chance« als vielmehr eine eher negative Sicht (Gefahr) vorherrscht.

Ein Risiko wird formal als Kombination (nicht als arithmetisches Produkt!) aus der – empirisch bestimmten – relativen Häufigkeit eines Ereignisses oder – objektiv – seiner Eintrittswahrscheinlichkeit und seiner Auswirkungen beschrieben.

Als Netto-Risiko bezeichnet man ein Risiko, dessen Eintrittswahrscheinlichkeit und/oder Auswirkung durch geeignete Maßnahmen bereits verringert worden ist.

In der Regel werden unter Risiken Netto-Risiken verstanden, da unbehandelte Risiken (Brutto-Risiken) lediglich bei vollkommen neuartigen Risiken und erstmalig bei ihrer Identifikation auftreten. Für sie muss, insbesondere, wenn Eintrittswahrscheinlichkeiten und/oder Auswirkungen hoch sind, umgehend eine Strategie zur Behandlung entwickelt werden. Brutto-Risiken sind daher häufig »Pseudorisiken« [Hunziker 2018b].

Vielfach werden weitere Risikobegriffe verwendet, die sich auch auf die IT übertragen lassen (vgl. Abschnitt 2.1.6).

Kann die Eintrittswahrscheinlichkeit für ein Risiko nicht quantitativ (mit Werten zwischen 0 und 1 bzw. den entsprechenden Prozentwerten) angegeben werden, wird eine qualitative Charakterisierung (bspw. in den Kategorien bestandsgefährdend/existenzbedrohend, sehr hoch, hoch, mittel, gering) verwendet.

Vielfach wird das Risiko auch als arithmetisches Produkt aus Eintrittswahrscheinlichkeit eines Ereignisses und seiner Auswirkungen definiert. Normen sprechen jedoch (siehe obige Definitionen) von einer Kombination. Eine solche Risikoermittlung kann daher unzulässig oder zumindest nicht aussagekräftig genug sein. Die häufig geäußerte Kritik an dieser Definition und Vorgehensweise ist, dass eine rein arithmetische Betrachtung des Produktes aus Eintrittswahrscheinlichkeit und Schadenshöhe mögliche Vorteile und Chancen, etwa aus dem Einsatz neuer, risikoreicher Technologien, unberücksichtigt lässt. Zudem unterschlägt sie den Umstand, dass sich Risiken selten als Punktwerte, sondern – realistischer – als Bandbreiten beschreiben lassen und daher über einen solchen Rechenweg nur selten angemessen abgebildet werden.

Es ist aus diesem Grund hilfreich, eine gewisse Unschärfe in der Bestimmung zuzulassen, Bereiche zu definieren und eine Festlegung auf exakte Werte nur dann vorzunehmen, wenn gesicherte Erkenntnisse vorliegen, die eine belastbare Berechnung erlauben (vgl. auch Abschnitt 2.1.5).

Auswirkungen von Risiken lassen sich in Geldeinheiten (bspw. Schadenskosten), als Zeitangabe (bspw. Dauer einer Störung oder eines Ausfalls) oder als Anzahl (bspw. betroffene IT-Systeme, Anwendungen, Personen) angeben. In anderen Fällen (bspw. Reputationsverlust) oder wenn unterschiedliche Arten von Schäden zusammenfassend dargestellt werden sollen, kann ein einheitenloser Punktwert (Score) verwendet werden.

Risiken können das Unternehmen als Ganzes oder in Teilen betreffen und im Zeitablauf unterschiedlich relevant sein.

Definition

Je nach Menge und Qualität der vorliegenden Informationen über Risiken wird unterschieden in:

»Unknown Unknowns«vollständig unbekannte und damit für Unternehmen extrem gefährliche Risiken. Sie werden vom Risikomanagement (vgl. Kap. 3) nicht erfasst. Oberstes Ziel ist es daher, alle Risiken zu kennen.»Known Unknowns«bekannte, aber noch nicht bewertete/eingeschätzte Risiken»Known Knowns«bekannte und bewertete/eingeschätzte Risiken, die behandelt werden

Im Außenverhältnis trägt die Unternehmensleitung stets die gesamte Verantwortung für Risiken.

Mit zunehmender Digitalisierung von Wirtschaft und Gesellschaft sind alle Informationssysteme mit allen ihren Elementen (vgl. Abb. 1–1) einer zunehmenden Vielfalt von Risiken ausgesetzt. Informationssysteme eines Unternehmens werden deshalb als schützenswerte IT-Ressource (IT Asset, IT-Vermögenswert) bezeichnet.

Ein Risiko im Kontext der Entwicklung, des Betriebs oder der Nutzung eines Informationssystems stellt eine Teilmenge aller in einem Unternehmen identifizierten Risiken dar und ist deshalb dem Grundsatz nach nicht anders definiert.

COBIT 5 for Risk definiert »IT risk as business risk, specifically the business risk associated with the use, ownership, operation, involvement, influcence and adoption of IT within an enterprise. IT risk consists of IT-related events that could potentially impact the business. IT risk can occur with both uncertain frequency and impact and creates challenges in meeting strategic goals and objectives.« In vergleichbarer Weise wird im ISACA-Glossary »IT Risk« als »the business risk associated with the use, ownership, operation, involvement, influence and adoption of IT within an enterprise« definiert.

Aufbauend auf diesen Definitionen, der Definition in ISO 31000: 2018 und dem Verständnis von Risiken in ISO/IEC 27000:2018 lässt sich entsprechend zusammenfassen:

Definition

Ein Risiko im Kontext von Informationssystemen konkretisiert über die obige Definition hinausgehend, mit welcher Wahrscheinlichkeit ein Ereignis mit IT-Bezug zu negativen materiellen und/oder immateriellen Auswirkungen auf die Geschäftstätigkeit des Unternehmens und seiner Partnern führt. Häufig sind mit entsprechenden Ereignissen interne oder externe Bedrohungen aufgrund von Schwachstellen des Informationssystems verbunden. Sie können dabei kurz-, mittel- und langfristig wirken, bis hin zur dauerhaften Betriebsunterbrechung.

Dabei werden zur weiteren Differenzierung des Risikobegriffs häufig zwei Sichtweisen unterschieden:

Das IT-Risiko, das als eher technisch begründeter Begriff von der Informationstechnologie, dem IT-System in Abbildung 1–1, ausgehend die übrigen Elemente des Informationssystems einbindet, insbesondere diejenigen, die IT-Systeme entwickeln und anwenden.

Das Informationssicherheitsrisiko, das als inhaltlich begründeter Begriff von den (Geschäfts-)Prozessen und deren Daten sowie den beteiligten Rollen ausgehend die technischen Voraussetzungen zur Nutzung einbezieht.

Ein zentraler Gedanke dieser Definition ist, dass alle Elemente des Informationssystems nach Abbildung 1–1 betroffen sein können und ebenso, dass alle Elemente Schwachstellen aufweisen können, nicht ausschließlich technische Elemente. Das Ziel des Schutzes von Informationen prägt diese Definition.

Zudem werden in der Praxis häufig weitere Risikobegriffe verwendet:

Cyberrisiko

Das BSI definiert Cybersicherheit als Arbeitsfeld, das sich mit »allen Aspekten der Sicherheit in der Informations- und Kommunikationstechnik« befasst. Dabei berücksichtigt Cybersicherheit in Erweiterung bisheriger IT-Sicherheitsbetrachtungen den gesamten Cyberraum. Als Cyberraum wird dabei die Gesamtheit der mit dem Internet und vergleichbaren Netzen verbundenen Informationssysteme gemäß Abbildung 1–1 verstanden. Entsprechend umfassen Cyberrisiken alle Risiken, die sich daraus ergeben. Das Financial Stability Board definiert Cyber Risk als »The combination of the probability of cyber incidents occurring and their impact«, wobei unter Cyber Incident ein »cyber event« verstanden wird, das »jeopardizes the cyber security of an information system or the information the system processes, stores or transmits; or violates the security policies, security procedures or acceptable use policies, whether resulting from malicious activity or not« [FSB 2018].

Cyberrisiken gehen häufig (aber nicht ausschließlich) auf Cyber Threats zurück, die als »circumstance with the potential to exploit one or more vulnerabilities that adversely affects cyber security« beschrieben werden [FSB 2018]. Entsprechende Bedrohungen (vgl. folgenden Abschnitt 2.1.1) sind dabei fortgeschrittene und zielgerichtete Angriffe auf Informationssysteme, die vielfach nur schwer zu entdecken und abzuwehren sind. Angreifer setzen dabei spezialisierte IT-Systeme bewusst und gezielt ein (vgl. auch [RiskNet 2019]).

Informationsrisiko

Informationsrisiken beschreiben alle Risiken, die auf Informationen wirken können. Häufig werden sie als Informationssicherheitsrisiken verstanden. Da der Begriff auch im Finanzdienstleistungsbereich verwendet wird, um anzuzeigen, dass Anleger auf Basis fehlender, unvollständiger, verspäteter oder falscher Informationen Entscheidungen treffen, sollte er – um Irrtümern vorzubeugen – im IT-Kontext nach Möglichkeit durch den Begriff Informationssicherheitsrisiko ersetzt werden.

IT-Sicherheitsrisiko

Das BSI stellt in seinem Glossar dar, dass IT-Sicherheit »sich an erster Stelle mit dem Schutz elektronisch gespeicherter Informationen und deren Verarbeitung« beschäftigt [BSI 2019]. Informationssicherheit hat den Schutz aller Informationen zum Ziel und ist daher weiter gefasst. IT-Sicherheitsrisiken sind deshalb als Teilmenge von Informationssicherheitsrisiken zu verstehen, weshalb dieser übergeordnete Begriff bevorzugt verwendet werden soll.

IT-Fehlerrisiko

IDW PS 330 definiert »die mit der konkreten Ausgestaltung des IT-Systems einhergehenden Risiken«, die »für wesentliche Fehler in der Rechnungslegung« verantwortlich sind, als IT-Fehlerrisiken [IDW 2002a].

Da alle Sichtweisen wichtig sind und ihre Berechtigung haben, wird im weiteren Verlauf der neutrale Begriff Risiko verwendet.

Praxishinweis

Konsens über die Risikodefinition

Zu Beginn aller Arbeiten mit Risiken und im Risikomanagement ist es wichtig, Konsens über die im Unternehmenskontext verwendeten Risikobegriffe herzustellen. Bleibt unklar, was genau im jeweiligen, insbesondere auch branchen- und/oder unternehmensabhängigen Kontext unter den verschiedenen Risikobegriffen verstanden wird, besteht die Gefahr, dass Lücken in der Risikobehandlung entstehen, weil Verantwortlichkeiten ungeregelt sind und scheinbare Einigkeit tatsächlich auf semantischen Missverständnissen beruht (vgl. auch die Handlungsempfehlungen in Abschnitt 2.1.4).

Im Rahmen beispielsweise eines Workshops sollte daher mit allen Beteiligten geklärt werden,

welche Risiken ein bestimmter Risikobegriff adressiert,in wessen Zuständigkeitsbereich (Verantwortung) diese Risiken fallen,wie die Koordination/Abstimmung untereinander erfolgen soll, falls sich Risiken nicht eindeutig zuordnen lassen, etwa, weil sie sich thematisch überschneiden.

Beteiligte lassen sich etwa über das Enterprise Risk Management oder eine Analyse der Aufbauorganisation ermitteln (vgl. auch Abschnitte 3.1.2, 3.2.1 und Kap. 4).

Ein Beispiel aus der Finanzdienstleistungsbranche soll die Problematik bei der Verwendung der Begriffe verdeutlichen: Die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) versteht unter IT-Risiken alle Risiken für die Vermögens- und Ertragslage von Finanzinstituten, die aufgrund von Mängeln entstehen, die das IT-Management bzw. die IT-Steuerung, die Verfügbarkeit, Vertraulichkeit, Integrität und Authentizität der Daten, das Interne Kontrollsystem der IT-Organisation, die IT-Strategie, -Leitlinien und -Aspekte der Geschäftsordnung oder den Einsatz von Informationstechnologie betreffen. Die BaFin orientiert sich damit an der Definition, die der Ausschuss der Europäischen Bankenaufsichtsbehörden (CEBS) im Jahr 2006 in den Leitlinien zur Anwendung des aufsichtlichen Überprüfungsverfahrens unter Säule II festlegte. IT-Risiken zählen demnach zu den operationellen Risiken [BaFin 2013]. Die Definition berührt zahlreiche unterschiedliche Tätigkeitsbereiche in der IT. Erfahrungsgemäß sind daher auch zahlreiche unterschiedliche Organisationseinheiten mit Risiken befasst. Aufgabe ist es nun, keine Lücken entstehen zu lassen. In den MaRisk [BaFin 2017] wird ebenfalls der Begriff »IT-Risiko« verwendet (AT 7.2), in den Bankaufsichtlichen Anforderungen an die IT (BAIT, vgl. [BaFin 2018]) wiederum werden die Begriffe »Risiko« und »Informationsrisiko« genutzt (Abschnitt II.3 in [BaFin 2018]). Auch hier muss geklärt werden, welche Organisationseinheiten wo Verantwortung für die Risiken tragen, um Aufgaben klar verteilen zu können.

Beispiel

Typische Risiken für Informationssysteme sind:

der Ausfall einer wichtigen Anwendung oder eines ICS, bedingt durch technische Störungen (bspw. Defekte, zu hohe Temperaturen und Softwareprobleme) oder gezielte Angriffe von außen (IT-Risiko)das Ausspähen von sensiblen Daten durch persönliche oder indirekte Beeinflussung des Personals durch Dritte, sogenanntes Social Engineering (Informationssicherheitsrisiko)das gezielte Angreifen einer Webanwendung im E-Commerce, die aufgrund eines noch nicht durch Patches behobenen Softwarefehlers eine Schwachstelle aufweist (Cyberrisiko)das Mithören des Datenverkehrs, insbesondere bei Verwendung von Funknetzwerken, etwa WLAN, Bluetooth, Zigbee, EnOcean (Informationssicherheitsrisiko)die Verletzung von Patenten bei der Programmierung von Software (Urheberrechtsverletzung), wenn dadurch die Verfügbarkeit der betroffenen Anwendung eingeschränkt ist oder Prozessrisiken aus deren Einsatz entstehen (IT-Risiko)erhebliche zeitliche Verzögerungen oder inhaltliche Unstimmigkeiten in einem wettbewerbskritischen IT-Projekt (IT-Risiko)

2.1.1Bedrohungen in der IT

Gefahr (Hazard, Danger) und Bedrohung (Threat) sind zentrale Begriffe im IT-Risikomanagement ([Kersten et al. 2011], S. 51, [Schmidt 2011], [BSI 2019]). ISO 73:2009 bezeichnet die Gefahr als »source of potential harm« und damit als mögliche »risk source«. ISACA bezieht den Begriff Bedrohung auf »anything (e.g. object, substance, human) that is capable of acting against an asset in a manner that can result in loss or harm« und grenzt den Begriff vom Risikobegriff ab.

Definition

Gefahr und Gefährdung

Die Gefahr wird als eine abstrakte Beschreibung von negativen, nicht oder nur schwer kalkulierbaren Sachverhalten definiert, die Schäden zur Folge haben. Eine Gefährdung ist konkret. Sie ist als Bedrohung zu verstehen, die konkret über eine Schwachstelle auf ein Objekt einwirkt (»Applied Threat«). Eine Bedrohung wird somit erst durch eine vorhandene Schwachstelle zur Gefährdung.

Bedrohung (Threat)

Eine Bedrohung ist eine reale Gefahr und weist damit einen präzisen zeitlichen, örtlichen, persönlichen, institutionellen oder materiellen Bezug auf. Sie beeinträchtigt die Verfügbarkeit, Integrität oder Vertraulichkeit von Informationen und kann Ursache für Schäden sein. Bedrohungen werden systematisiert und in Bedrohungskatalogen zusammengefasst.

Bedrohungen können nach folgenden Aspekten systematisiert werden:

Höhere Gewalt

Bedrohungen, die durch den Menschen oder das Unternehmen nicht beeinflusst werden können. Hierzu zählen beispielsweise Naturgewalten oder Kriege und andere Großereignisse im Unternehmensumfeld.

Vorsätzliche Handlungen

Unter vorsätzlichen Handlungen werden alle grob fahrlässigen Handlungen und alle kriminellen Aktivitäten (insbesondere Cyberkriminalität) zusammengefasst.

Solche Vorfälle werden meist öffentlich, wenn Kundendaten oder andere sensible Informationen missbraucht oder kompromittiert werden. Ein bekanntes Beispiel ist der Diebstahl von Kundendaten eines Spielekonsolen-Herstellers im Jahr 2011. Versäumnisse des Unternehmens wurden im Frühjahr 2013 in England mit einer hohen Geldstrafe geahndet. Ein weiteres Beispiel ist der Missbrauch von Social-Media-Daten in den Jahren 2015/16 zu Zwecken der Wahlmanipulation, dessen Rechtsfolgen im Herbst 2018 noch unklar sind.

Technisches Versagen

Technisches Versagen ist durch Materialermüdung, Alterung oder temporär unzulässige Betriebszustände verursacht.

Beispielsweise kann die Alterung von Speicherbausteinen in einem Server zu Datenverlusten, Instabilitäten oder vollständiger Nichtverfügbarkeit führen.

Jede Bedrohung besitzt eine eigene Kritikalität. Sie leitet sich aus den Wirkungen auf die Betriebskontinuität ab und wird analog zur Klassifikation der Risiken angegeben. Ob die Bedrohung für das Unternehmen relevant ist, hängt – analog zur Risikoakzeptanz (vgl. Abschnitt 2.2.4) – davon ab, welche Bedeutung das bedrohte Element des Informationssystems für die Geschäftstätigkeit hat und welche Kritikalität die Bedrohung besitzt.

2.1.2Schwachstellen in der IT

Bedrohungen sind zwar ursächlich für negative Auswirkungen auf das Unternehmen und damit für Risiken. Aber erst durch die Existenz von Schwachstellen ist ein Unternehmen dem aus der Bedrohung resultierenden Risiko ausgesetzt. Neben der Bedrohung ist die Schwachstelle daher ein weiterer, sehr zentrale Begriff im IT-Risikomanagement. Das ISACA Glossary und die ISACA Glossary Terms (www.isaca.org) beispielsweise beziehen eine Schwachstelle (Vulnerability) auf »control conditions that are deemed to be deficient relative to requirements or the threat levels beeing faced. It is a weakness in design, implementation, operation or internal control of a process that could expose the system to adverse threats from threat events.« In ISO 73:2009 ist die Schwachstelle definiert als »intrinsic properties of something resulting in susceptibility to a risk source that can lead to an event with a consequence«.

Definition

Schwachstelle (Verwundbarkeit, Vulnerability, Weakness, Angriffspunkt)

Die Schwachstelle stellt einen Zustand der Unvollkommenheit einer Maßnahme zur Risikobeherrschung dar. Sie beschreibt die Verbindung zwischen einem Risiko und den dazu gehörenden Bedrohungen sowie den ergriffenen Maßnahmen.

Eine Schwachstelle ermöglicht es einer Bedrohung, auf das Unternehmen, seine IT-Infrastruktur, Anwendungen und letztlich Geschäftsprozesse tatsächlich einzuwirken. Sie ist eine für den Eintritt eines Risikos ursächlich gefährliche Eigenschaft des Informationssystems.

Um Schwachstellen gegen Bedrohungen abzuschirmen, werden als Bestandteil des Internen Kontrollsystems (vgl. Kap. 11) Maßnahmen, im IKS als Kontrollen (engl.: Controls) bezeichnet, etabliert und fortlaufend verbessert (vgl. Abb. 2–1).

Abb. 2–1Bedrohungen, Schwachstellen und Risiken (modifiziert nach [Prokein 2008], S. 2)

Das BSI spricht in diesem Zusammenhang von Gefährdungen. Eine Gefährdung ist eine Bedrohung, die über eine Schwachstelle konkret auf die IT einwirkt. Im Grundschutz-Kompendium [BSI 2018] sind solche Gefährdungen systematisiert und detailliert beschrieben. Im Unterschied zum Risikobegriff umfasst die Gefährdung keine Bewertung, inwieweit ein betrachtetes Schadensszenario für das Unternehmen relevant ist [BSI 2019].

Während früher eine Vielzahl von Forschungseinrichtungen systematisch nach Schwachstellen in Anwendungen und der IT-Infrastruktur gesucht und das Wissen darüber unentgeltlich verbreitet hat, hat sich mittlerweile der Verkauf von Wissen über neue Schwachstellen und Möglichkeiten etabliert. Existiert entsprechender Schad- bzw. Angriffscode (sog. Exploit), kann die Schwachstelle unmittelbar ausgenutzt werden, weshalb Schwachstellen mitunter auch in »Vulnerability« (zunächst nur analytische Überlegungen, keine praktische Ausnutzbarkeit) und Exploits unterschieden werden (vgl. [Königs 2017], S. 61). Besonders gefährlich ist Angriffscode, der gleichzeitig mit dem Bekanntwerden einer Schwachstelle vorliegt (sog. Zero-Day-Exploit).

Neben IT-Infrastrukturelementen, Betriebssystemen und Anwendungen sind davon vermehrt auch industrielle Steuerungssysteme und kritische Infrastrukturen (etwa in der Energiewirtschaft, im Gesundheitswesen, im Lebensmittelbereich oder der Telekommunikationsbranche) betroffen. Unternehmen dürfen daher nicht mehr darauf vertrauen, als Erste über neue Schwachstellen in ihren IT-Systemen informiert zu werden.

Analog zu Gefahren und Bedrohungen können auch Schwachstellen klassifiziert werden. Unterschieden werden können:

Technische Schwachstellen

Sie beziehen sich auf Anwendungen, die IT-Infrastruktur und die technischen Komponenten des IT-Umfelds (Gebäude, Sicherungssysteme). Beispielsweise kann eine Anwendung fehlerhaft programmiert sein, Hardware kann schlecht konstruiert sein, die Klimaanlage des Serverraums oder die Stromversorgung für die Server können unterdimensioniert sein, Redundanz kann fehlen, auch kann die Wand in einem Serverraum zum Nachbarraum lediglich bis zur abgehängten, nicht bis zur tragenden Decke hochgezogen sein. Schwachstellen können aber auch dadurch entstehen, dass eine Datenbank nur eine einzige, von allen genutzte, nicht personalisierte Zugriffstechnik auf Tabellen kennt.

Personelle Schwachstellen

Sie beziehen sich auf alle Personen, die in irgendeinem Bezug zur IT stehen, und sind die Folge von Unachtsamkeit oder fahrlässigem Handeln. Das verantwortliche IT-Personal ist meist nicht ausreichend sensibilisiert oder qualifiziert, etwa für die Bedrohungen durch Social Engineering. Unkenntnis begünstigte beispielsweise den Diebstahl eines Dienstleister-Notebooks mit den gesamten Einwohnermeldedaten einer Gemeinde im April 2013. Im konkreten Fall verzichtete das Personal darauf, die Festplatte des Notebooks zu verschlüsseln.

Auch das Übersehen von technischen Unzulänglichkeiten, sich ankündigenden technischen Störungen, Konstruktionsfehlern und das Nichterkennen von Programmierfehlern gehören dazu.

Organisatorische Schwachstellen

Sie beziehen sich auf alle aufbau- und ablauforganisatorischen Regelungen. Der Administratorzugang beispielsweise ist nicht über ein Passwort abgesichert, damit das gesamte Personal im Notfall vollen Zugriff auf den Server hat. Ein Geschäftsprozess enthält keine Funktionstrennung nach dem Vier-Augen-Prinzip. Eine Archivdatei mit streng vertraulichen Daten wird zwar einem Prozess folgend, jedoch unverschlüsselt über das Internet übertragen.

Leider ist es aufgrund der zunehmenden Komplexität in der IT, der fortschreitenden IT-Durchdringung und fehlender Fakten über Bedrohungen immer schwieriger, die Bedeutung von Schwachstellen einzuschätzen. Aktuelle, aus der Praxis abgeleitete Bewertungskriterien und -maßstäbe, die in einem Framework systematisiert werden, können jedoch dabei helfen. Ein Beispiel für ein solches Framework ist das Common Vulnerability Scoring System (CVSS), das aktuell in der Version 3.0 vorliegt (vgl. auch [Königs 2017] und www.first.org/cvss).

Definition

Angriff

Liegt eine Schwachstelle vor, muss jederzeit mit einem Angriff auf das Angriffsziel über diese Schwachstelle, den Angriffspunkt, gerechnet werden. Angriffe sind in der Regel vorsätzlich ausgeführt und gehen stets auf unberechtigte und unerwünschte Aktivitäten zurück. Es entsteht dabei ein Schaden und/oder der Angreifer kann sich Vorteile verschaffen oder unbeteiligte Dritte schädigen. Angriffe können auch im Auftrag Dritter erfolgen. Als Auslöser (die Ursache) für Angriffe gelten Menschen.

Als Angriffspfad (auch Angriffsweg, Angriffsgraph) bezeichnet man den logischen Pfad zu einem Angriffspunkt. Wird die gewählte Angriffstechnik ergänzt, spricht man von einem Angriffsvektor.

(vgl. [Schmidt 2011], S. 553, [BSI 2019])

Beispiel

Mögliche Angriffspfade sind:

der Weg vom Internet über die Perimeter-Firewall (Angriffspunkt), die demilitarisierte Zone (DMZ), die innere Firewall und mehrere Intranet-Router bis zum ERP-System (Angriffsziel)der direkte Weg über die lokale Administrationskonsole (Angriffspunkt) in einem Rechenzentrum zum zentralen Data Warehouse (Angriffsziel)

Mögliche Angriffsvektoren sind:

der Weg über einen Exploit (Angriffswerkzeug) in den fehlerhaften Programmcode des Betriebssystems (Angriffspunkt) und von dort in die Speicherbereiche von laufenden (Server-)Anwendungen (Angriffsziel)Personen (Angriffspunkt) aus dem eigenen Personal oder von Fremdfirmen, die im Rahmen von Social Engineering ahnungslos und unbedarft, aus Neugierde oder auch aus Angst vermeintlich harmlose Fragen des Angreifers beantworten oder sich zur Installation von unbekannter Software verleiten lassen (Angriffswerkzeug) und ihm so den Zugriff auf kritische Anwendungen (Angriffsziel) ermöglichen.

Der Angriffspfad ist nicht immer offensichtlich. Manche Angriffspfade entstehen erst, wenn mehrere Bedingungen gleichzeitig zutreffen. Ein Beispiel ist eine unbeaufsichtigte Administratorkonsole bei gleichzeitig nicht verschlossener Tür des Kontrollraums.

Da Angriffspfade unterschiedlich komplex sein können, ist es unterschiedlich wahrscheinlich, dass ein Angriffspfad erkannt und genutzt wird. In vielen Fällen ist zudem der Aufwand zu hoch oder es dauert zu lange, das Ziel zu erreichen.

Maßnahmen zur Beherrschung der Schwachstelle im Rahmen der Behandlung von Risiken können die Angriffspfade nach aktuellem Stand der Technik oder Best Practices (bspw. Richtlinien, Sanktionen bei Nichteinhaltung, konsequente Qualifikationen und Awareness-Trainings) verlängern, blockieren oder abschirmen, jedoch nicht vollständig aufheben – denn die Maßnahmen selbst können nicht oder nur bedingt wirksam sein.

Ein Angriffspfad gilt erst dann als beseitigt, wenn alle Schwachstellen entlang des Pfades endgültig nicht mehr existieren. Trotz aller ergriffenen Maßnahmen verbleibt mindestens ein Angriffspfad. Würde kein einziger Angriffspfad existieren, läge vollkommene Sicherheit vor.

Praxishinweis

Die Überlegungen zu Bedrohungen und Schwachstellen sind relativ abstrakt. Warum sind sie dennoch hilfreich?

Erfahrungen zeigen, dass die Beschäftigung mit Bedrohungen und Schwachstellen bei der Ableitung von Ursache-Wirkungs-Beziehungen und der Identifikation von Risiken helfen können.

Vorteil: Sie zwingen zu sorgfältigem logischem Denken und reduzieren die Wahrscheinlichkeit, aufgrund falsch verstandener Zusammenhänge in die falschen Maßnahmen zur Risikobehandlung zu investieren.

Umgangssprachlich werden Bedrohung (Threat) und Risiko oftmals gleichgesetzt.

Bedrohungen und Risiken unterscheiden sich jedoch, auch wenn diese Trennung vielfach als akademisch empfunden wird. So kann die Bedrohung ein bereits bei anderen Unternehmen mehrfach angewandter Exploit einer Schwachstelle in einer kritischen Software sein. Das daraus resultierende Risiko hingegen ist beispielsweise Nichtverfügbarkeit eines bestimmten IT-Systems, der Abfluss von vertraulichen Daten oder die Zerstörung der gesamten Daten (etwa durch einen Verschlüsselungs-Trojaner, der über den Exploit eingeschleust werden kann).

Auch aus diesem Grund ist es hilfreich, Bedrohungen, Schwachstellen und Risiken getrennt voneinander zu betrachten und sorgfältig in Beziehung zu setzen (vgl. auch die Definition zum Risikobegriff in Abschnitt 2.1).

2.1.3Schutzziele

Bei Eintritt eines Risikos können grundsätzlich ein oder mehrere Schutzziele verletzt werden. Die wesentlichen vier Schutzziele sind:

Vertraulichkeit (Confidentiality)

Die Vertraulichkeit ist verletzt, wenn ein unberechtigter Zugang zu den Daten in einem Informationssystem jederzeit oder auch nur für wenige Augenblicke möglich ist oder wenn er bereits erfolgte. Der verletzte Schutz kann Unsicherheit auslösen und Schäden zur Folge haben, die auch Dritte betreffen. Typische Beispiele sind das Ausspähen von Nutzerdaten, das Eindringen in Datenbestände oder das Mitverfolgen der Kommunikation. Vertraulichkeit kann beispielsweise durch Verschlüsselung hergestellt werden.

Integrität (Integrity)

Bereits wenn unsachgemäße Modifikationen an einem Informationssystem, etwa durch Fehler im Berechtigungssystem, vorgenommen werden könnten, gilt die Integrität der Daten als verletzt, bis das eindeutige Gegenteil bewiesen ist. Gleiches gilt bei Cyberangriffen, bis nachgewiesen ist, dass tatsächlich keine Veränderungen an den Datenbeständen vorgenommen wurden. Auch in diesem Fall können die entstandenen Schäden Dritte betreffen. Im Rahmen der Prüfung des Jahresabschlusses ist ein Hinweis auf die (mögliche) Verletzung der Integrität abschlussrelevanter Finanzinformationen ein wesentliches Risiko. Die Integrität kann beispielsweise durch ein Identitätsmanagement, Zugangs- und Berechtigungssystem, weitere hard- und softwarebasierte Sicherheitsmechanismen, fachliche und technische Abstimmungen der Datenbestände oder ein geordnetes Change-Management-Verfahren von Anwendungen sichergestellt werden.

Eng verbunden mit der Integrität ist die Echtheit. Die Echtheit bestätigt, dass Daten nicht unerwünscht verändert wurden. Echtheit kann beispielsweise durch Prüfsummen oder digitale Wasserzeichen sichergestellt werden. Sie wird mitunter auch als getrenntes Schutzziel ausgewiesen.

Ebenfalls mit der Integrität verbunden – jedoch als eine Art Gegenpol – ist die Kontingenz (Contigency). Während die Integrität beschreibt, dass etwas so ist, wie es ist, stellt Kontingenz die Frage, ob etwas anders sein könnte, als es scheint.

Verfügbarkeit (Availability)

Sind Funktionen eines Informationssystems unabhängig von einer konkreten Ursache beeinträchtigt oder gänzlich inaktiv, ist die Verfügbarkeit verletzt. Betroffen sein können auch Dritte, z. B. Kunden von Streaming- oder Cloud-basierten Smart-Home-Lösungen. Verfügbarkeit kann beispielsweise durch Redundanz von Hard- und Software oder durch Datenspiegelungen/Backups sichergestellt werden.

Zurechenbarkeit (Accountability), Transparenz (Transparency) und Authentizität (Authenticity)

Nehmen Unberechtigte die Identität Dritter an oder könnten sie dies jederzeit tun, um in deren Namen zu handeln, ist die Zurechenbarkeit verletzt. Beispielsweise wird auf diesem Weg die im elektronischen Geschäftsverkehr zwingend notwendige elektronische Verbindlichkeit aufgehoben, etwa durch gefälschte Onlinebanking-Identitäten oder durch die Nutzung gefälschter Kreditkartendaten. Zurechenbarkeit, Authentizität und damit Transparenz ist dann gewährleistet, wenn eindeutig ist, wer für bestimmte Aktivitäten verantwortlich ist. Dieses Schutzziel kann beispielsweise durch Signaturen erreicht werden.

Der Fokus bei Informationssicherheitsrisiken liegt insbesondere auf diesen vier Schutzzielen. IT-Risiken wiederum können weitere Aspekte, wie Innovationsfähigkeit und Wirtschaftlichkeit, mit berücksichtigen.

Weitere Schutzziele im Kontext der Vertraulichkeit können sein [Bedner & Ackermann 2010]:

Unverkettbarkeit

(

Unlinkability

)

Stellt sicher, dass mehrere, hintereinander ablaufende Aktivitäten nicht miteinander in Verbindung gebracht werden können und auf diesem Weg Anonymität hergestellt werden kann.

Nichtverfolgbarkeit

(

Untracability

) und

Unbeobachtbarkeit

(

Unobservability

)

Stellt sicher, dass keine Rückverfolgbarkeit möglich und damit ebenfalls Anonymität oder zumindest Pseudonymität sichergestellt ist sowie dass Aktivitäten für Dritte verborgen bleiben.

Ein weiteres Schutzziel im Kontext der Zurechenbarkeit und Transparenz ist die Revisionsfähigkeit (Reviewability). Sie stellt Nachprüfbarkeit und Nachvollziehbarkeit sicher.

Ergänzende Schutzziele im Kontext der Verfügbarkeit sind Verlässlichkeit (Reliability) und Beherrschbarkeit (Controllability). Insbesondere letzteres Schutzziel könnte im Kontext der künstlichen Intelligenz (KI/AI) interessant sein bzw. werden, da ausgeschlossen werden sollte, dass IT-Systeme ein »Eigenleben« entwickeln können. Zu diesem Themenkomplex sollte frühzeitig, umfassend und unter Einbezug aller Stakeholder innerhalb des Unternehmens, aber auch mit dem Unternehmensumfeld diskutiert werden.

Oftmals wird auch die IT-Sicherheit (IT Security) als weiteres wesentliches Schutzziel angeführt. Die drei oben genannten Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit beschreiben jedoch alle wesentlichen Aspekte der IT-Sicherheit.

Alle Schutzziele können durch vorsätzlich falsch oder fahrlässig handelnde Personen oder andere Risikofaktoren (vgl. folgenden Abschnitt 2.1.4) verletzt werden. Motivation und Zielsetzung von Personen spielen erst bei einer tiefer gehenden Analyse eine Rolle, nicht aber für die Verletzung des Schutzziels selbst.

2.1.4Risikopotenzial

Definition

Der Begriff Risikopotenzial (Risikovolumen, -dimension, Tragweite) ist ein Maß für die Schadenshöhe von Risiken [Schneck 2010]. Das Risikopotenzial wird aus der Eintrittswahrscheinlichkeit und den Auswirkungen ermittelt und bezieht sich immer auf einen Zeitraum. Es präzisiert damit obige Risikodefinition. Bei Risiken im Kontext von Informationssystemen kann zwischen direktem und indirektem Risikopotenzial unterschieden werden ([Seibold 2006], S. 13 f.). Das direkte Risikopotenzial wird aus den Schäden direkt in der IT (originäre Risiken) ermittelt. Das indirekte Risikopotenzial beschreibt den Business Impact und folgt aus den Schäden in den betroffenen Geschäftsprozessen auf Anwenderseite (Anwenderrisiken).

Eingetretene Risiken müssen für die Fachabteilungen nicht zwingend einen Schadensfall darstellen. Risiken in und aus der IT gelten für die Fachabteilungen vielmehr als Ursache für fachliche Risiken in den Geschäftsprozessen ([Seibold 2006], S. 11). In dieser Sichtweise gehen Risiken stets von den genutzten IT-Systemen aus. Viele Unternehmen unterscheiden dabei mit Blick auf das Risikopotenzial zwischen Auswirkungen auf die Produktion/Fertigung (Operations) und solchen auf die Verwaltung (Backoffice).

Solange Fehler in Anwendungen und Performance-Probleme oder andere Störungen in der IT keine Auswirkungen auf die Geschäftstätigkeit haben, werden sie von den Fachabteilungen vielfach nicht als Risiken wahrgenommen – wohl aber von der IT.

Aus Sicht der IT wiederum sind die IT-Systeme einer Vielzahl von Risiken ausgesetzt.

Beispiel

Ein zentrales Anwendungssystem, etwa das ERP-System, fällt am Freitag um 22 Uhr aus. Die reguläre Datensicherung und wichtige geplante Wartungsarbeiten können erst mit vierstündiger Verspätung beginnen, weil zunächst der Fehler gesucht und behoben werden musste. Alle Arbeiten werden jedoch rechtzeitig bis Montag zu Beginn der ersten Schicht um 4:30 Uhr behoben, die Fachabteilungen bemerken nichts.

In der IT beginnt im Anschluss an die Arbeiten jedoch die Suche nach der Ursache (Root Cause Analysis, vgl. Kap. 6), weil sich ein solcher Ausfall in keinem Fall während der regulären Betriebszeiten wiederholen darf.

Vielfach werden in solchen Situationen Managementebenen außerhalb der IT erst dann informiert, wenn erkennbar ist, dass die Ursache jederzeit erneut auftreten und zu Betriebsunterbrechungen führen kann und Zeit und Budget zur Behandlung benötigt wird.

Während bei Anwenderrisiken fast immer eine gute Zuordnung zu den Geschäftsprozessen möglich ist, lassen sich Auswirkungen von Störungen der IT-Infrastruktur nicht immer oder nur mit hohem Aufwand einem bestimmten Geschäftsprozess zuordnen. Zwar gibt es Methoden und Werkzeuge zur Ermittlung von Ursache-Wirkungs-Beziehungen (vgl. Kap. 6). Je komplexer die IT-Infrastrukturen jedoch sind, desto häufiger müssen für Zuordnungen zwischen Geschäftsprozessen und einzelnen Infrastrukturelementen mehr oder weniger strittige und damit zusätzlich risikobehaftete Annahmen getroffen werden. Dies gilt vielfach besonders bei Cloud-Dienstleistungen, da anders als im Outsourcing nur selten Einblick in die Strukturen möglich ist und vorgelegte Zertifizierungen und Prüfungsberichte vielfach nicht alle Fragen beantworten (können oder wollen).

Definition »weicher« Begriffe im Risikokontext

Für Risiken wird entsprechend der Risikodefinition in der Regel eine Gesamtbetrachtung ausgehend von Eintrittswahrscheinlichkeit und Schaden vorgenommen. Insbesondere größere Unternehmen mit ausreichenden finanziellen Spielräumen machen davon Gebrauch. Grundvoraussetzung ist, dass sich Wahrscheinlichkeiten weitgehend objektiv ermitteln und Schäden weitgehend monetär bewerten lassen. Hilfreich ist zudem eine angemessen realitätsnahe Betrachtung des Kosten-Nutzen-Verhältnisses einer Risikobehandlung.

Damit stellt sich die Frage, was unter »ausreichend«, »weitgehend« und »angemessen« zu verstehen ist. In Vorgaben, Literatur und Vorträgen werden Präzisierungen für diese und verwandte Begriffe nur selten vorgenommen, weil sich Verhältnisse nur selten verallgemeinern lassen. Jedes Unternehmen legt »sein« Begriffsverständnis also sinnvollerweise individuell fest (vgl. Tab. 2–1).

Handlungsempfehlung

Schaffung eines einheitlichen Begriffsverständnisses im IT-Risikomanagement zur Vermeidung von Missverständnissen

1.

Bestandsaufnahme

Abfrage der benötigten Informationen beispielsweise in Workshops, über Onlinebefragungen im Intranet oder Experteninterviews unter Berücksichtigung bereits vorhandener Organisationsstrukturen (und damit möglicher Wissens-/Informationsquellen)

■Welche Begriffe werden verwendet?

■Bei welchen Begriffen besteht inhaltlich/fachlich Unklarheit?

■Welche Begriffe sind im Unternehmen bereits anders belegt?

■Wo gibt es weitere Mehrdeutigkeiten und falsch verwendete Synonyme?

■Welche Begriffe lassen sich nicht mit konkreten Werten (Definition, Euro, Stunden, Anzahlen) beschreiben?

2.

Abstimmung

Einigung auf ein einheitliches Begriffsverständnis

Gibt es ein Enterprise Risk Management (vgl. Kap. 3)? Wenn ja, liegen dort bereits Begriffsdefinitionen vor?

Gibt es ein akzeptiertes Rahmenwerk, das die Begriffe definiert hat? Sind diese Begriffe direkt verwendbar oder müssen sie (teilweise) auf Unternehmensspezifika angepasst werden?

3.

Klärung und Entscheidung

Erstellung einer abgestimmten Liste der Begriffe in Form eines Glossars zur Entscheidung durch das Management (bspw. IT-Leitung, besser: CIO/CDO, GRC-Management, Unternehmensleitung). Eine solche Liste kann auch Mehrfachverwendungen oder alternative Verwendungen unter Angabe der verwendenden Organisationseinheiten und einer kurzen Begründung für die »Abweichung« enthalten.

4.

Kommunikation

■schriftliche Fixierung der erzielten Ergebnisse

■Klärung des Verteilers der Informationen

■Bereitstellung im Intranet, über zentrale Verzeichnisse oder andere geeignete Informationswege für alle Betroffenen

Tab. 2–1Einheitliches Begriffsverständnis im IT-Risikomanagement

2.1.5Der Wahrscheinlichkeitsbegriff und das Risiko

Der Berechnung und Beurteilung von Wahrscheinlichkeiten kommt eine besondere Bedeutung zu, denn Zeitpunkt, Dauer und Umfang von Ereignissen und Auswirkungen können nicht vorab »gemessen« werden. Es ist daher das Ziel, mithilfe von Wahrscheinlichkeiten anzugeben,

wann

,

wo

,

wie

Ereignisse und Auswirkungen auftreten und

was

genau sie

wie oft

auslöst.

Für die Beschreibung werden – soweit dies möglich ist – Verteilungsfunktionen genutzt, etwa die Dreiecks-, Poisson-, Normal-/Gauß-, PERT-, Weibull- oder Compoundverteilung (vgl. [Romeike 2018]).

Bei allen Überlegungen und Berechnungen wird dabei auf möglichst umfassende, genaue, mit der betrachteten Situation vergleich-bare und verlässliche statistische Daten, Erfahrungswerte/Heuristiken oder Schätzungen zurückgegriffen. Hinsichtlich der Vergleichbarkeit und Genauigkeit sind Daten aus dem eigenen Unternehmen ideal, andererseits wird jedes Unternehmen hoffen, möglichst wenig eigene Erfahrungen sammeln zu müssen.

Beispiel

Die Wahrscheinlichkeit für einen Serverausfall beträgt empirisch aus Vorjahresdaten ermittelt 0,2% in 365 Tagen (also eine Nichtverfügbarkeit von 0,73 Tage oder 17,52 Stunden). Der Ausfall eines Servers verursacht nach Angaben aus dem Controlling einen Gesamtschaden unter Berücksichtigung aller relevanten Kostenarten von 20.000€ je Stunde. Das Risiko beträgt demnach 17,52 Stunden × 20.000€, also 350.400€ je Jahr.

Bedroht ein Schaden das Unternehmen in besonderer Weise (wie im folgenden Beispiel der Brandfall in einem Serverraum) und sind solche Ereignisse sehr selten, liegen praktisch nie verlässliche Daten vor. Deshalb werden dann für die Risikoberechnung alternative, aufwendigere Methoden eingesetzt (vgl. Kap. 6).

Beispiel

Angenommen, alle 25 Jahre entsteht ein Brand in einem von 5.000 Serverräumen, für die eine CO2-Löschanlage zu aufwendig oder teuer wäre. Ferner lassen sich die Auswirkungen wegen des hohen Wertes der dort gelagerten Daten mit 50 Millionen Euro angeben. Bei Anwendung der einfachen Berechnungsformeln würde das Risiko in diesem fiktiven Beispiel je Jahr 50 M€/25 Jahre, also 2 Millionen betragen, verteilt auf alle Serverräume also 400€.

Es ist offensichtlich, dass eine solche simple Multiplikation wie im Beispiel unzulässig ist. Denn solche Schäden bedrohen nicht nur mittelständische Unternehmen in ihrer Existenz. Der Eintritt des Risikos würde die finanziellen Möglichkeiten auch vieler großer Unternehmen übersteigen. Das Risiko ist damit wesentlich. In dieser Konstellation wird daher bei den Überlegungen zur richtigen Reaktion stets ausgehend von möglichen Auswirkungen auf die Geschäftstätigkeit (Business Impact) oder gar das Fortbestehen des Unternehmens (Going-Concern-Prinzip) nach wirksamen Möglichkeiten zur Behandlung gesucht.

Liegen keine eigenen Daten vor, wird soweit möglich auf statistisches Material aus externen Quellen zur Ermittlung von Wahrscheinlichkeiten zurückgegriffen, etwa in der Internetsicherheit (Angriffsstatistiken) oder bei Zuverlässigkeitsanalysen für Hardware.

Diesem Aspekt kommt für die Sektoren der kritischen Infrastruktur (KRITIS) besondere Bedeutung zu. Da KRITIS-Unternehmen mit ihren Produkten und Dienstleistungen eine besondere Stellung für das öffentliche Gemeinwohl einnehmen, sind verlässliche Daten über die Risikolage notwendig. Neben der gesetzlichen Meldepflicht an das BSI nach § 8b Abs. 4 BSIG arbeiten mehrere Institutionen und Projekte daran, das Risikolagebild in den KRITIS-Sektoren und der Industrie insgesamt fortlaufend zu verfeinern und somit den betroffenen Unternehmen Datenmaterial zugänglich zu machen, um das unternehmenseigene IT-Risikomanagement entsprechend ausgestalten zu können.

Ob im KRITIS-Umfeld oder in allen anderen Unternehmen: Stets jedoch ist es zwingend notwendig, externe Daten auf ihre Anwendbarkeit sowie auf notwendige Annahmen für die Verwendung zu prüfen und das Ergebnis dieser Übertragbarkeitsprüfung zu dokumentieren, ehe die Daten in weiteren Überlegungen genutzt werden (vgl. Tab. 2–2). Denn die Verwendung von externen Daten zur Ermittlung von Wahrscheinlichkeiten und Schadenshöhen stellt bei unzureichender Anwendbarkeit selbst ein Risiko dar.

Handlungsempfehlung

Klärung der Eignung externer Daten für das IT-Risikomanagement

1.

Sammlung

■Welche Daten stehen zur Verfügung (Erreichbarkeit der Quellen, Inhalt, Menge, Detailliertheit, Genauigkeit, Seriosität/Ruf des Anbieters, Kosten)?

■Wie aktuell sind die Daten? Daten, die länger als ein Jahr nicht aktualisiert wurden, sollten nicht oder nur mit großer Vorsicht genutzt werden. Daten auf Basis von Zeitreihen sind prinzipiell geeignet, allerdings müssen die Rahmenbedingungen (technologische Änderungen, Änderungen in der Gesellschaft usw.) berücksichtigt sein.

■Müssen Annahmen getroffen werden, um die Daten nutzen zu können?

2.

Prüfung

Passen die Daten hinsichtlich:

■der eigenen Anwendungen und IT-Infrastruktur?

■des Unternehmens (Branche, Größe, Rechtsform)?

■der Zielsetzung (welches Risiko soll betrachtet werden)?

■verwendeter Methoden zur Ermittlung solcher Werte (Erhebungs- und ggf. Berechnungs-/Aggregationsmethoden)? Ist transparent, wie die Daten entstanden sind?