E-Book, Deutsch, 228 Seiten, E-Book
Aufbau und Betrieb gemäß Prozess-Referenzmodell der ISO/IEC TS 27022
E-Book, Deutsch, 228 Seiten, E-Book
ISBN: 978-3-7910-6140-5
Verlag: Schäffer-Poeschel Verlag
Format: EPUB
Kopierschutz: 6 - ePub Watermark
Prof. Dr. Knut Haufe ist Director bei Ernst & Young GmbH WPG und Professor für Wirtschaftsinformatik (Cyber Security Governance) an der SRH Berlin University of Applied Sciences. Er berät führende Organisationen der öffentlichen Verwaltung sowie im Bereich kritischer Infrastrukturen zur Planung und Etablierung von Informationssicherheits-Managementsystemen gemäß ISO/IEC 27001 / BSI-IT-Grundschutz.
Autoren/Hrsg.
Fachgebiete
Weitere Infos & Material
3.4 Informationssicherheitsmanagementsystem
Der Teil des Managementsystems, der sich mit Informationssicherheit beschäftigt, wird als Informationssicherheitsmanagementsystem (ISMS) bezeichnet. Das übergeordnete Ziel eines ISMS ist die Steuerung – nicht die Beseitigung – der Informationssicherheitsrisiken. Es soll sichergestellt werden, dass Informationen ein angemessenes Schutzniveau entsprechend ihrer Bedeutung für die Organisation erhalten. Im Folgenden wird auf wesentliche Aspekte der Aufbauorganisation eingegangen. Die Ablauforganisation innerhalb eines ISMS wird in Kapitel 6 detailliert in Form eines ISMS-Prozessreferenzmodells beschrieben. Die Gesamtverantwortung für die Steuerung und Realisierung eines angemessenen Informationssicherheitsniveaus verbleibt immer bei der obersten Management- oder Leitungsebene.
Aus der Verantwortung der obersten Leitungsebene und der Realisierung des ISMS durch den ISB ergibt sich die Notwendigkeit einer angemessenen Steuerung durch die oberste Leitungsebene. Die oberste Leitungsebene muss daher die Organisationsziele und damit die im Einklang stehende strategische Sicherheitsziele sowie die Informationssicherheitsstrategie vorgeben und das ISMS über Bewertungen und gegebenenfalls Anpassungen der Ziele steuern.
Diese Verantwortung ist nicht delegierbar. Lediglich die Zuständigkeit hinsichtlich der Umsetzung kann delegiert werden.
Daher wird ein ISMS häufig durch den Informationssicherheitsbeauftragten (ISB) betrieben. Oftmals wird der ISB auch Chief Information Security Officer (CISO) oder Chief Security Officer (CSO) genannt. Für den ISB ergeben sich konkrete Aufgaben in Form der Rollenbeschreibung. Auch diese unterscheiden sich in der Praxis sehr stark – es gibt beispielsweise ISB in Form einer klassischen Stabsstelle ohne Entscheidungs- und Weisungsbefugnisse, aber auch ISB mit konkreten Weisungsbefugnissen an alle Mitarbeiter.
Bei der organisatorischen Verankerung des ISB existieren viele Möglichkeiten, die alle Vor- und Nachteile haben. Die Erfahrungen sind gemischt – die allgemein »beste« Lösung gibt es nicht.
Weitere relevante Rollen für die Aufbauorganisation sind beispielsweise:
-
COO – Chief Operations Officer – leitet das operative Geschäft
-
CIO – Chief Information Officer – leitet Einsatz von IT
-
CDO – Chief Digital Officer – leitet die digitale Transformation
-
CTO – Chief Technology Officer – technischer Leiter/Direktor
Tabelle 2 – Beispiele von ISMS-Aufbauorganisationsformen veranschaulicht verschiedene Organisationsformen sowie deren Vor- und Nachteile.
| Kriterien | Option 1 Unterhalb CIO, | Option 2 Unterhalb CIO, | Option 3 Gleiche Ebene wie CIO, | Option 4 Gleiche Ebene wie CIO, |
| 1 | Geschäfts- und Risikoorientierung | Kann über geeignete Form der Anbindung an Geschäftseinheiten sichergestellt werden | Kann über geeignete Form der Anbindung an Geschäftseinheiten sichergestellt werden | Kann über geeignete Form der Anbindung an Geschäftseinheiten sichergestellt werden | Kann über geeignete Form der Anbindung an Geschäftseinheiten sichergestellt werden |
| 2 | Ganzheitlichkeit | Einfach für IT, oft schwieriger für OT durch Bereichsgrenzen | Einfach für IT, oft schwieriger für OT durch Bereichsgrenzen | Strukturell neutral möglich für IT und OT, da auf Augenhöhe – aber keine unmittelbare Nähe zu einem der Bereiche | Erschwert für IT, schwierig für OT durch Isolation |
| 3 | Unabhängigkeit | Potenzieller Zielkonflikt zwischen CIO und CISO | Kein Zielkonflikt mit CIO durch indirekte Reporting-Linie zum Vorstand und Eskalationsmöglichkeit | Zweitstärkste Form der Unabhängigkeit | Stärkste Form der Unabhängigkeit |
| 4 | Technologienähe | CISO eng an IT, aber strukturell getrennt von CDO und CTO (IoT, OT) | CISO eng an IT und über indirekte Reporting-Linie zu COO auch Nähe zu IoT und OT möglich | CISO auf Augenhöhe mit relevanten Technologiebereichen (IT, OT, IoT), dennoch keine unmittelbare Nähe | Isoliert von Technologiebereichen |
| 5 | Durchschlagskraft | Keine Nähe zum Vorstand, aber eindeutiger Berichtsweg | Nah am Geschehen (IT), unmittelbare Eskalationsoption, bewährte und pragmatische Organisationsform, aber: bedingter Effekt in streng hierarchischen Organisationen | Nähe zu CDO, CIO, CTO und Möglichkeit zu Einflussnahme auf Vorstand | Möglichkeit der Einflussnahme auf Vorstand, jedoch isoliert von Technologiebereichen |
| 6 | Wirtschaftlichkeit | Hohe Synergieeffekte mit IT, Effizienzverlust durch höheren Abstimmungs- und Eskalationsbedarf | Hohe Synergieeffekte mit IT, Effizienzverlust durch höheren Abstimmungs- und Eskalationsbedarf, wirtschaftlichste Lösung durch Nutzung von Synergien | Höhere Kosten durch Aufwertung von CISO, keine Synergien mit CIO (nicht kostenoptimal), Effizienzgewinn durch Abstimmung auf Augenhöhe | Höhere Kosten durch Aufwertung von CISO und Ferne zu CDO und CTO, Effizienzgewinn durch Abstimmung auf Augenhöhe |
Tab. 2 – Beispiele von ISMS-Aufbauorganisationsformen
Expertentipp
Grundsätzlich sollte die organisatorische Verankerung des ISB anhand definierter Kriterien bewertet und gewählt werden. Empfehlenswert und durch diverse Anforderungen definiert sind Unabhängigkeit, Ganzheitlichkeit sowie Wirtschaftlichkeit der Arbeit des ISB. Darüber hinaus können Geschäfts- und Risikoorientierung, Technologienähe und Durchschlagskraft herangezogen werden. Durch diesen Ansatz lassen sich nachvollziehbare Entscheidungen zur Aufbauorganisation und Verankerung der Informationssicherheit innerhalb der Organisation treffen. Erfahrungsgemäß sind hier folgende Optionen vorteilhaft:
-
die Verankerung des ISB unterhalb des CIO – aber mit direkter Berichtslinie zur Organisationsleitung/Geschäftsführung/zum Vorstand,
-
die Verankerung des ISB unabhängig und auf gleicher Ebene zum CIO direkt unterhalb der Organisationsleitung/Geschäftsführung/zum Vorstand.
Für mittelständische und kleinere Organisationen sind entsprechende Anpassungen vorzunehmen. Hier hat jede Organisationsform ihre Daseinsberechtigung und ist im Kontext der individuellen Rahmenbedingungen auszuwählen beziehungsweise zu bewerten. Sollte der ISB zugleich weitere Rollen innehaben, resultieren daraus häufig sogenannte Interessenkonflikte.
Ein solcher Interessenkonflikt entsteht beispielsweise, wenn der ISB gleichzeitig IT-Leiter oder Administrator ist. In der Rolle als ISB definiert er Sicherheitsvorgaben und kontrolliert deren Einhaltung. Gleichzeitig müsste er diese operativ umsetzen in der Rolle als Mitarbeiter der IT-Abteilung. In diesen Fällen sind entsprechende kompensierende Kontrollen zu etablieren.
Das ISMS beziehungsweise der ISB ist grundsätzlich verantwortlich für die Umsetzung aller definierten Sicherheitsmaßnahmen. Vielmehr agiert er als ein Dienstleister für die Fachabteilungen/Werteverantwortlichen, welcher es den Fachabteilungen/Werteverantwortlichen ermöglicht, sich über die individuellen Sicherheitsanforderungen klar zu werden.
Im Wesentlichen identifizieren das ISMS beziehungsweise der ISB auf Basis dieser fachspezifischen Anforderungen und den übergeordneten Vorgaben/Anforderungen potenzielle Risiken, analysieren und bewerten diese und identifizieren Risikobehandlungsoptionen.
Die Auswahl und Umsetzung dieser Handlungsoptionen obliegt dann der Verantwortung der Fachabteilungen/Werteverantwortlichen. Hier besteht in der Praxis häufig sowohl in den Fachabteilungen als auch im ISMS ein abweichendes Rollenverständnis:
Oft wird die Auswahl, Umsetzung und Finanzierung der Sicherheitsmaßnahmen vom ISMS erwartet. Dies geht dann oft mit überzogenen Anforderungen der Fachabteilungen/Werteverantwortlichen an die Informationssicherheit einher, da diese ja nicht von den Fachabteilungen finanziert werden müssen.
Mindestens genauso oft scheitern ISMS-Projekte an der mangelnden Auskunftsfähigkeit der IT-Abteilung aufgrund unzureichender IT-Dokumentation. Ein Scheitern ist dann vorprogrammiert, wenn vom ISMS beziehungsweise dem ISMS-Projekt versucht wird, die...
