Über den Security Consulting (Praxis-)Leitfaden
kurz: SCL

Als ich vor einiger Zeit vom Security Management ins Security Consulting wechselte, musste ich feststellen, dass es nur wenig Praxis-bezogene Hilfestellungen für Consulting in diesem Bereich gibt. Ohne die Erfahrungen, die ich zuvor einige Jahre im Management sammeln konnte, wäre mein Umstieg wesentlich schwieriger geworden.
Im Consulting erlebe ich nun, dass viele Firmen im Bereich Informationssicherheit immer wieder die gleichen oder sehr ähnliche Probleme haben. Oft sind diese jedoch leichter zu lösen sind, als es anfangs den Anschein hat. Man muss nur die richtigen Wege finden. Und die finden sich nicht selten in Management-Methoden.
Mit diesem Artikel starte ich eine Artikel-Serie, in der ich in unregelmäßigen Abständen über solche typischen Probleme schreiben, vor allem aber praktische Lösungsansätze aufzeigen werde. Denn WAS gemacht werden muss, kann man auf vielen Seiten über Cyber-Security und Informationssicherheit nachlesen. WIE das Was umgesetzt werden soll, wird jedoch selten behandelt und stellt so manchen Informationssicherheitsbeauftragten (ISB) in seinem Unternehmen vor scheinbar unlösbare Probleme. In dieser Serie gibt es nun also das Wie zum Was. 😊

Anmerkung: Wenn ich im Folgenden von dem ISB (Informationssicherheitsbeauftragter) spreche, dann steht dies synonym für eine oder mehrere Personen, egal welchen Geschlechts, die in einem Unternehmen für das Thema (Informations-)Sicherheit und Datenschutz zuständig ist bzw. sind.

TL;DR

Oft haben ISB das Problem, dass ihr ISMS im Unternehmen zu wenig Beachtung findet. Dem kann man entgegenwirken, indem man bereits bei der Implementierung des ISMS die Stakeholder in dessen Aufbau involviert, die Mitarbeiter umfangreich über die Fortschritte informiert und die Geschäftsführung ihre Unterstützung für das ISMS sichtbar macht. Dazu gibt es einige Hebel, die man nutzen kann:

• Ein Unterstützerbrief der Geschäftsführung und andere Möglichkeiten, wie die Geschäftsführung zeigen kann, dass sie hinter dem ISMS steht.
• Betroffene (oder Vertreter ihrer Interessen) zu einem festen Bestandteil beim Review-Verfahren in der Dokumenten-Lenkung machen, so dass ihre Interessen bei der Definition von Richtlinien und Verfahren berücksichtigt werden müssen (zumindest soweit es die Norm erlaubt).
• Mit einem internen Security-Newsletter regelmäßig über den Stand der Informationssicherheit und Fortschritte beim ISMS informieren.
• Schulungen richtig nutzen, mit ihnen die Mitarbeiter abholen und Verständnis für die Vorgaben von Richtlinien aufbauen.
• Alle freigegebenen Dokumente des ISMS, so wie auch wesentliche Berichte aus den Aufzeichnungen, für alle Mitarbeiter zugängig machen.
• Ownership für Assets und Risiken verteilen, um Awareness für die Risiken im Unternehmen zu schaffen, mit den Ownern die richtigen Fachleute in die Risiko-Minderung einzubinden und den ISB bei komplexen Verfahren, wie der BIA oder der Risiko-Bewertung, zu unterstützen.
• Einen Teil des regelmäßigen Sicherheitsbericht für das Management auch an alle Mitarbeiter senden, damit jeder im Unternehmen über mögliche Risiken und Schwachstellen informiert ist, und ein paar Augen mehr auf mögliche Unregelmäßigkeiten in den betroffenen Bereichen achten.

Das Problem: Ein ISMS auf Papier

Ein häufiges Problem, auf das ISB und andere Personen, die ein ISMS in einem Unternehmen implementieren wollen, stoßen, ist die scheinbar mangelnde Bereitschaft der Mitarbeiter, die Richtlinien in ihren Fachbereichen auch anzuwenden oder generell mit dem ISB zusammenzuarbeiten. Oft wird am Sicherheitsbeauftragten vorbei gearbeitet und er bekommt eher zufällig mit, wenn irgendwo wieder neue Datenflüsse geschaffen werden. Aber fehlt wirklich die Bereitschaft, oder liegen die Probleme vielleicht woanders?

Als Consultant kommt man immer wieder in Unternehmen, die bereits ein ISMS haben, und nun eine Zertifizierung anstreben. Um zu ermitteln, was sie an ihrem ISMS noch anpassen müssen, führen wir dann zumeist zuerst eine Gap-Analyse durch. Und nicht selten stellt man dabei fest, dass das sogenannte ISMS eigentlich nur eine Sammlung von Richtlinien und Protokollen ist, an die sich im besten Fall noch die IT-Abteilung hält. Naja, zumindest an einige davon. Viele der anderen Mitarbeiter wissen oft gar nicht, dass es ein ISMS im Unternehmen gibt. Jene, die es wissen, haben nur mal "irgendwann was davon gehört, aber so richtig passiert ist danach eigentlich nicht" oder wissen, dass "Frau oder Herr XYZ (zumeist die/der ISB) sich irgendwie damit befasst, aber was sie/er da genau macht... keine Ahnung".

Das sind klassische Fälle, wo das ISMS nur auf dem Papier existiert. Doch damit ein ISMS mehr ist, als eine Ansammlung von Richtlinien, die kaum jemand kennt, muss es zu einem gelebten System im Unternehmen gemacht werden. Die besten Richtlinien werden bei der Zertifizierung nicht helfen, wenn sie von den Mitarbeitern nicht eingehalten werden. Es funktioniert nur dann, wenn das "Projekt ISMS" im Unternehmen ausreichend Sichtbarkeit bekommt und alle Interessengruppen im Unternehmen bereits bei dessen Aufbau involviert werden. Um das zu erreichen, muss man alle Bereiche im Unternehmen richtig einbinden. Im Folgenden zeige ich ein paar Methoden auf, wie man bereits bei der Implementierung des ISMS dafür sorgt, dass das ganze Unternehmen am Aufbau des ISMS beteiligt ist, Raum für Wissenstransfer frei gemacht und Sichtbarkeit für Informationssicherheit geschaffen wird.

Projektbeginn - Ein Unterstützerbrief der Geschäftsleitung

Schon wenn man beginnt, im Unternehmen ein ISMS zu implementieren, ist es wichtig, dass ALLE MITARBEITER davon erfahren. Eine kurze Erwähnung als internes Projekt im Newsletter der HR-Abteilung reicht dafür zumeist nicht aus. Soll das ISMS bspw. nach ISO/IEC 27001 zertifiziert werden, muss nachgewiesen werden, dass die Geschäftsführung das ISMS ausreichend unterstützt. Und damit kann sie bereits zum Projektstart loslegen.

Dazu schickt sie zur Bekanntgabe des Projekts selbst eine E-Mail an alle Mitarbeiter mit einem, möglichst von der gesamten Geschäftsführung unterschriebenen Unterstützerschreiben, in dem die Mitarbeiter über folgende Dinge informiert werden:

• Was ist ein ISMS und warum soll es eingeführt werden?
• Wer ist der ISB, mit welchen Aufgaben wird er betraut und wie kann er kontaktiert werden?
• Die Verpflichtung für alle Mitarbeiter, mit dem ISB zusammenzuarbeiten.

Der Effekt, den man nach dem Versand eines solchen Dokuments (und ggf. noch als Aushang am schwarzen Brett oder bei der Kaffeemaschine) beobachten kann ist, dass der ISB plötzlich weniger Schwierigkeiten hat, Termine für notwendige Schulungen oder für Interviews mit Fachbereichsleitern usw. zu bekommen. Auch die Bereitstellung notwendiger Informationen aus den Fachabteilungen erfolgt zumeist viel schneller und mit weniger Diskussion, wenn die Geschäftsführung auf diese Weise das ISMS zur Chefsache erklärt hat. Und nicht zuletzt wird auch die Übertragung von Verantwortlichkeiten, wie z.B. die Ownership für Risiken und Assets, viel unkomplizierter. Denn jedem ist klar: Geht der ISB zum CEO, weil jemand nicht oder nur widerwillig mit ihm zusammenarbeitet, wird er von der Leitungsebene Unterstützung bekommen.

Richtlinien (richtig) implementieren

Wie oben bereits erwähnt, findet man in Unternehmen häufig Richtlinien zu Sicherheitsthemen, die den Mitarbeitern nicht ausreichend bekannt sind. Für dich als Consultant sind diese erstmal wertlos. Denn der Fakt, dass kaum ein Mitarbeiter sie kennt, deutet auf zwei grundlegende Probleme hin:

1. Die von den Richtlinien betroffenen Abteilungen/Fachbereiche/Mitarbeiter wurden nicht in die Erstellung der Richtlinien eingebunden. Damit ist es sehr wahrscheinlich, dass die Prozesse, auf die diese Richtlinien angewendet werden sollen, nicht ausreichend bei ihrer Ausgestaltung beachtet wurden. Sie werden somit eher viele neue Probleme schaffen, anstatt die Sicherheitsschwachstellen in den vorhandenen Prozessen effizient zu adressieren.
2. Es fehlt ein Prozess, der dafür sorgt, dass alle Mitarbeiter, inkl. Neueinsteigern, über die Richtlinien, ihren Inhalt und wie sie in der Praxis anzuwenden sind, informiert und bei Bedarf geschult werden.

Man muss also Strukturen schaffen, die diese beiden Probleme lösen. Schon bei der Erstellung einer Richtlinie kann man dafür sorgen, dass sie in den betroffenen Bereichen des Unternehmens bekannt und nach der Freigabe auch tatsächlich befolgt wird. Dazu kann man das Review- und Freigabe-Verfahren für Dokumente nutzen, das man im ISMS sowieso benötigt.

Im Verfahren zur Dokumentenlenkung legt man fest, dass der Entwurf von Richtlinien und Verfahren vor der Freigabe immer von Vertretern der sogenannten "interessierten Parteien" geprüft werden muss. Das heißt, dass bspw. die Abteilungsleiter das Review der Richtlinie durchführen und ihren Input dazu geben können, wenn ihre Abteilung von einer Richtlinie betroffen sein wird. Sollte sich durch die Reaktionen auf das Review größerer Diskussionsbedarf zeigen, beruft der ISB ein Meeting mit den Stakeholdern ein, in dem die Probleme, Sorgen und Einwände lösungsorientiert angegangen werden. In diesem Meeting hat der ISB auch gleich die Möglichkeit zu erklären, was mit der Richtlinie letztendlich bewirkt werden soll und welche Anforderungen die ISO-Norm dabei stellt. Zusammen mit den Stakeholdern kann dann überlegt werden, wie man diese Anforderungen in die vorhandenen Prozesse einbauen kann, anstatt komplett neue Prozesse zu etablieren oder die bestehenden zu kompliziert zu machen.

Bewährt hat sich auch, dass bereits vor dem Entwurf einer Richtlinie mit den Vertretern der interessierten Parteien eine Art Schulung abgehalten wird, bei der die Hintergründe zu der Richtlinie, die Gründe für deren Einführung und die Anforderungen, die sich aus der ISO-Norm dafür ergeben, erläutert werden. So findet immer auch ein Wissenstransfer vom ISB zum Team statt. Auch kann mehr Verständnis für die Notwendigkeit von Maßnahmen bei den davon Betroffenen aufgebaut werden. Dieses Meeting sollte der ISB auch nutzen, um sich über die Prozesse und Ressourcen, die von der Richtlinie betroffen sein werden, zu informieren, damit er die sich daraus ergebenden Bedingungen und Anforderungen beim Entwurf der Richtlinie beachten kann. Erfahrungsgemäß gibt es im Review-Prozess weitaus weniger Diskussionsbedarf, wenn solche Schulungen im Voraus abgehalten werden.

Sollte trotzdem keine Einigung zwischen ISB und Stakeholdern bei der Ausgestaltung einer Richtlinie oder eines Verfahrens erreicht werden, wird in letzter Instanz die Geschäftsführung involviert, um eine Entscheidung zu treffen. Letztendlich wird die Verpflichtung aller Mitarbeiter, die Richtlinien so einzuhalten, wie sie freigegeben wurden, auch dadurch betont, dass die finale Freigabe durch die Geschäftsführung erfolgt und sie damit zu Mitarbeiter-Anweisungen werden.

Diese Vorgehensweise kommt dem ISMS in verschiedener Hinsicht zugute. Zum einen werden bereits bei der Erstellung alle zukünftigen Betroffenen einer Richtlinie identifiziert. Das können alle Mitarbeiter sein, wie z.B. bei der Informationssicherheitsleitlinie, oder auch nur bestimmte Mitarbeiter-Gruppen, wie bspw. das IT-Team bei einer Kryptographie-Richtlinie oder dem Patch- und Update-Management. Die identifizierten interessierten Parteien kann man gleich zusammen mit den zugehörigen Kontaktinformationen in einem Dokument vermerken (z.B. einer Excel-Tabelle, wenn keine ISMS-Software im Einsatz ist), das als "Dokumenten-Verteiler" genutzt wird. Wird eine neue Version einer Richtlinie veröffentlicht, schaut man einfach in dieses Dokument und schickt eine entsprechende Information an alle im Verteiler vermerkten Parteien.

Zum anderen steigt auch die Bereitschaft eine Richtlinie tatsächlich umzusetzen, wenn alle Stakeholder oder ihre Vertreter bei deren Erstellung involviert sind. Durch den Review-Prozess wird ein Verständnis für die Anforderungen der ISO-Norm bei allen Beteiligten aufgebaut und gleichzeitig werden auch die Anforderungen der Betroffenen, soweit es zulässig ist, berücksichtigt. Damit ist der ISB nicht mehr jemand, der immer nur Vorschriften und alles kompliziert macht. Er wird stattdessen eher als jemand wahrgenommen, der kompromissbereit ist und eine Lösung sucht, mit der alle gut leben können. Das macht die Arbeit des ISB erfahrungsgemäß viel einfacher. Und glücklicherweise lässt die ISO-Norm oft auch genug Spielraum, um seine Richtlinien an die vorhandenen Strukturen im Unternehmen anpassen zu können.

Die finale Freigabe einer Richtlinie oder eines Verfahrens sollte aber, wenn möglich, immer durch die Geschäftsführung in einem formellen Verfahren erfolgen. Dieses Verfahren sollte beinhalten, dass die Geschäftsführung per Unterschrift die Freigabe eines Dokuments oder einer neuen Version eines Dokuments erteilt. So kann das "Management Commitment", das die ISO-Norm fordert, auch relativ einfach nachgewiesen werden. Außerdem wird sichergestellt, dass die Richtlinien sich in dem Rahmen bewegen, den das Management anstrebt und / oder für vertretbar hält.

Leider wird in vielen Unternehmen auf die Benachrichtigung aller betroffenen Stakeholder bei der Veröffentlichung neuer Versionen einer Richtlinie gern verzichtet. Ganz nach dem Motto "die aktuellsten Versionen der Richtlinien kann man sowieso im Intranet einsehen" werden Stakeholder höchstens dann benachrichtigt, wenn sich grundlegend an der Sicherheitspolitik des Unternehmens etwas ändert, also quasi nur dann, wenn die Informationssicherheitsleitlinie von der Änderung betroffen ist. Damit verzichtet man auf eine wichtige Awareness-Maßnahme. Denn je mehr ich die Mitarbeiter über Fortschritte und Änderungen im ISMS informiere, umso mehr Aufmerksamkeit für Sicherheitsthemen schaffe ich. Generell sollte man jede Möglichkeit nutzen, mit der Mitarbeiter auf Informationssicherheitsthemen aufmerksam gemacht werden können.

Der Security-Newsletter

Die ISO-Norm fordert, dass die Mitarbeiter eines Unternehmens regelmäßig über Veränderungen in der Bedrohungslage und sonstige relevante Informationen aus der Informationssicherheit informiert werden. Viele implementieren dies als Security-Newsletter in ihrem Unternehmen, lassen diesen aber oft durch externe Dienstleister zusammenstellen und automatisiert verschicken.

Besser ist es, wenn diese Aufgabe dem ISB übertragen wird. Neben allgemeine News aus der Informationssicherheit und zur aktuellen Bedrohungslage, wie man sie auch von den Dienstleistern erhält, kann so auch über Fortschritte und Veränderungen im ISMS berichtet werden. Dadurch bleibt das Projekt in den Köpfen der Mitarbeiter präsent.

Wird in diesem Newsletter immer über neue oder geänderte Richtlinien informiert, erfahren Mitarbeiter auch etwas über die Existenz jener Richtlinien, von denen sie selbst nicht betroffen sind. Das kann dazu beitragen, dass mehr Verständnis für die Arbeitsweisen in den verschiedenen Bereichen des Unternehmens aufgebaut wird, weil die Mitarbeiter mitbekommen, welche Anforderungen diese erfüllen müssen. Besonders hilfreich ist dies, wenn in einem Bereich Nachweispflichten bestehen und deswegen z.B. Unterschriften von involvierten Mitarbeitern gefordert werden. Dann muss nicht jedes Mal aufs Neue erklärt werden, warum jemand eine Unterschrift leisten soll. Oder wenn bspw. ein Mitarbeiter selbst nicht direkt an der Auswahl von Dienstleistern beteiligt ist, kann es dennoch unter Umständen hilfreich sein, wenn er die Anforderungen an Dienstleister aus der zugehörigen Richtlinie kennt, z.B. wenn er nach einer bestimmten Software sucht, die seine Arbeit erleichtern soll.

Übrigens kann man mit dem internen Newsletter auch das Management Commitment verbessern. Dazu muss sich jedoch die Geschäftsführung dazu verpflichten, einmal im Monat einen kurzen Beitrag zu den Fortschritten und Änderungen im ISMS für den Newsletter zu schreiben. Ein recht einfacher Weg für das Management, sein Interesse am und die Unterstützung für das ISMS präsent zu machen. Diese Verpflichtung bedingt natürlich, dass das Management sich regelmäßig über sämtliche Fortschritte im ISMS informiert bzw. informieren lässt. (Tipp: Als Berater sollte man bei einem solchen Projekt sicherstellen, dass mindestens monatlich ein kurzer Bericht an das Management geht. Dieses sollte über im Berichtszeitraum neu umgesetzte Maßnahmen und sonstige Änderungen am ISMS informieren. Auch sollte er die für den kommenden Berichtszeitraum geplanten Maßnahmen sowie den voraussichtlich dafür notwendigen Ressourcen-Bedarf auflisten.)

Schulungen

Auch wenn bei der Erstellung von Richtlinien und sonstiger Sicherheitsmaßnahmen die Stakeholder bereits involviert sind, sollte man dennoch dafür sorgen, dass alle von einer Richtlinie betroffenen Mitarbeiter über den Inhalt der Richtlinie, den Ablauf des Prozesses usw. informiert werden. Denn in den meisten Fällen wird man die Richtlinien nur mit einzelnen Vertretern der betroffenen Mitarbeiter-Gruppen entwerfen, damit der involvierte Personenkreis überschaubar bleibt und nicht unnötig Ressourcen gebunden werden. Anstatt also mit der gesamten IT-Abteilung die Anforderungen an Authentifizierungssysteme zu diskutieren, sind am Review-Verfahren der zugehörigen Richtlinie eher nur der CTO und 1-2 Leute aus dem IT-Team, die diese Systeme verwalten, beteiligt. Dennoch müssen alle Sysadmins nach der Freigabe über diese Richtlinie informiert werden.

Bei einer technischen Richtlinie für das IT-Team mag es ausreichen, wenn das Team von den Reviewern über die Anforderungen informiert wird und per E-Mail eine Benachrichtigung des ISB bei Inkrafttreten der Richtlinie erfolgt. Doch gerade, wenn es um Richtlinien geht, die sich eher auf Prozesse auswirken, wie z.B. eine Richtlinie zur Remote-Arbeit und Home-Office für Außendienstmitarbeiter, sollte man als ISB sicherstellen, dass der Inhalt der Richtlinie von den Betroffenen auch wirklich zur Kenntnis genommen und verstanden wurde.

Dies kann man am besten durch Schulungen bei der Einführung neuer Richtlinien sicherstellen, die man für alle Betroffenen verpflichtend macht. In dieser Schulung wird ihnen erklärt:

• Warum gibt es diese Richtlinie?
• Wie ist die Richtlinie mit dem ISMS verbunden und was wirkt ggf. auf diese ein? (Z.B. die darin erwähnten zugehörigen Richtlinien kurz besprechen.)
• Welche Anforderungen der ISO 27001 werden durch diese Richtlinie adressiert?
• Wie wirkt sich die Richtlinie im Arbeitsalltag der Betroffenen aus? Worauf müssen sie achten? Was dürfen sie tun / nicht mehr tun? usw.

Natürlich sollte man mit dem HR-Team zusammen sicherstellen, dass solche themenspezifischen Schulungen auch für New-Joiner abgehalten werden. Der oben bereits erwähnte Dokumenten-Verteiler kann hierfür übrigens für HR einen guten Anlaufpunkt bieten, um selbst ermitteln zu können, von welchen Richtlinien ein neuer Mitarbeiter betroffen sein wird. Dazu müssen sie nur nachschauen, zu welchen interessierten Parteien er gehören wird.

In Unternehmen, die sich gerade in einem schnellen Wachstum befinden, wird man jedoch nicht für jeden neuen Mitarbeiter mehrere themenspezifische Schulungen persönlich durchführen können. Sonst ist der ISB nur noch mit Schulungen beschäftigt. Man sollte daher die themenspezifischen Schulungen möglichst in ein Format bringen, mit dem sich die neuen Mitarbeiter selbstständig schulen können. Das kann eine PowerPoint-Präsentation sein, in der die Notizen dazu genutzt werden, die Schulungsinhalte zu vermitteln. Oder man zeichnet eine Schulung als Video auf, was sich besonders dann anbietet, wenn man sie sowieso über einen Video-Chat durchführt.

Die generelle Sicherheitsschulungen empfehle ich jedoch immer als persönliche Schulung durchzuführen. Es mag noch ok sein, wenn man seine Mitarbeiter vor eine Video-Schulung setzt, solange es nur darum geht, den Schutz personenbezogener Daten nach DSGVO-Anforderungen einzuhalten. Hat man jedoch in seinem Unternehmen ein ISMS nach ISO 27001 implementiert, werden die meisten Mitarbeiter zwangsläufig mit dessen Prozessen und Anforderungen konfrontiert. Eine generelle Schulung zu Datenschutz und Informationssicherheit, die alle Mitarbeiter erhalten, sollte daher auf das ISMS des Unternehmens eingehen und zumindest dessen Kontext, die Sicherheitsziele und die Verantwortlichkeiten vermitteln. Auch können New-Joiner in einer solchen Schulung gleich auf die evtl. noch kommenden themenspezifischen Schulungen vorbereitet werden.

Keine unnötigen Geheimnisse im ISMS

Schon als ich im Security-Management tätig war, konnte ich nicht verstehen, warum manche Geschäftsführer es ein Geheimnis aus Audit-Berichte oder Risiko-Bewertungen machen und diese nur für einen eingeschränkten Personenkreis einsehbar sind. Fakt ist: Man verbessert die Sicherheit ganz sicher nicht, wenn man die Mitarbeiter über potenzielle Gefahren im Dunkeln lässt. Stattdessen bewirkt man das Gegenteil. Sind sich alle Mitarbeiter der Gefahren bewusst, die ihren Bereich betreffen, achten sie mehr auf Anzeichen von Unregelmäßigkeiten. So werden mögliche Sicherheitsvorfälle oftmals schneller erkannt.

Auch gibt es keinen Grund, warum man Richtlinien oder andere Dokumente aus dem ISMS nur jenen zugänglich machen sollte, die direkt davon betroffen sind. Zumeist wird das damit begründet, dass Mitarbeiter überfordert seien, wenn sie alle Dokumente einsehen können. Natürlich setze ich einen Mitarbeiter nicht vor die ISMS-Dokumentation, damit er diese vollständig liest. Er erhält immer eine Liste der Dokumente (bzw. von Links auf diese), die für ihn relevant sind. Doch sollten Mitarbeiter immer die Möglichkeit haben, über ihren Tellerrand hinauszuschauen und, wenn sie Interesse daran haben, einen ganzheitlichen Blick auf das ISMS zu erhalten. So mancher Mitarbeiter ist dadurch schon zu einem wertvollen Unterstützer und Fürsprecher in seiner Abteilung für den ISB geworden und trägt damit erheblich zur Awareness in seinem Team bei.

Veröffentlicht man Aufzeichnungen wie Audit-Berichte oder Risiko-Bewertungen so, dass sie für alle Mitarbeiter einsehbar sind, können Mitarbeiter auch von sich aus tätig werden und proaktiv Schutzmaßnahmen in ihrem Bereich implementieren. Man muss nur dafür sorgen, dass sie immer den ISB darüber informieren.

Allerdings hat sich auch gezeigt, dass man manchmal unnötige Aufreger vermeiden kann, wenn man Richtlinien in ihrer Entwurf- und Review-Phase nur den daran beteiligten Personen zugänglich macht. So wird nicht unnötig in den Teams über Vorgaben diskutiert, die in der finalen Version in einer ganz anderen Weise umgesetzt werden, als es der erste Entwurf vorsieht, weil die Abstimmung mit den Fachabteilungen noch nicht stattgefunden hatte. Allerdings müssen alle Reviewer auch sicherstellen, dass sie ihr Team ausreichend involvieren und deren Input in ihre Reviews einbringen.

Natürlich gibt es auch Informationen, vor allem Aufzeichnungen, die schon aufgrund ihrer Inhalte, wie z.B. IP-Adressen, Kontaktdaten zu Stakeholdern u.ä., nach dem Need-to-Know-Prinzip behandelt werden sollten oder müssen. Jedoch sollten zumindest alle aktuell freigegebenen und damit gültigen Richtlinien für jeden Mitarbeiter einsehbar sein. Deswegen sollten sie auch generell als "intern" und nicht als "geheim" eingestuft werden. Das spart auch Arbeit bei der Administration, weil nicht jedes Mal jemand Zugriff erteilen muss, wenn ein Mitarbeiter in ein neues Aufgabengebiet kommt, wo neue Richtlinien für seine Tätigkeiten relevant werden.

Ownership

Eines der wichtigsten Werkzeuge zur Verteilung von Verantwortlichkeiten und den damit einhergehenden Aufgaben, ist die Verteilung von Eigentümerschaften (Ownership). Nicht selten herrscht die Vorstellung, dass die Ownership für alles, was das ISMS betrifft, beim ISB liegt. Doch das ist grundlegend verkehrt. Zum einen wäre die Arbeitslast, die mit einem ISMS einher geht, für einen einzelnen ISB kaum zu bewältigen, wenn dieser noch in das Tagesgeschäft eingebunden ist. Schaut man sich bspw. allein eine Asset-basierte Risiko-Bewertung an, kann man sich vorstellen, dass eine einzelne Person damit mehrere Tage oder, je nach Größe des Unternehmens, sogar Wochen beschäftigt sein würde.

Deswegen gibt es 2 Bereiche, in denen der ISB Ownership übertragen sollte:

1. Assets
2. Risiken

Die Ownership für Assets stellt sicher, dass jene Mitarbeiter in Themen wie die Risiko-Bewertung für die Assets einbezogen werden, die die Expertise dafür haben und ständig damit arbeiten. Ist bspw. das IT-Team unterteilt in ein Server-Team und ein Team für die Office-IT, wird auch die Ownership für die jeweiligen IT-Systeme entsprechend auf diese Teams verteilt. Sie werden also immer dann involviert, wenn irgendwas im ISMS ihre Assets betrifft, wie z.B. die Risiko-Bewertung oder die Implementierung von Kontrollen / Maßnahmen zur Risiko-Minderung. Außerdem werden sie verpflichtet, einen Prozess oder eine technische Lösung in ihrem Verantwortungsbereich zu implementieren, der sicherstellt, dass ihre Assets im Asset-Verzeichnis und die notwendigen Dokumentationen immer aktuell gehalten werden. Diesen Prozess müssen sie dokumentieren und die Dokumentation an den ISB schicken, damit dieser den Prozess in der Richtlinie zur Asset-Verwaltung berücksichtigen kann.

Oft beziehen sich Risiken jedoch nicht auf Assets, sondern auf Prozesse, in die wiederum Assets involviert sein können. Und manche Risiken beziehen sich auch auf mehrere Assets oder Asset-Gruppen. Beispielsweise ist Feuer für Papier-Unterlagen genauso eine Bedrohung wie für die Server oder die Maschinen in der Werkhalle. Um die Risiko-Minderung durch jene koordinieren zu lassen, die die entsprechenden Befugnisse und Kompetenzen dazu haben, wird die Ownership für Risiken unabhängig von der Ownership der betroffenen Assets vergeben. Ownership für ein Risiko kann dabei einer Teamleitung oder einer anderen Führungskraft übertragen werden, in deren Bereich die Auswirkung des Risikos fällt. Risiko-Eigentümer sind dafür verantwortlich, dass die im Rahmen des Risiko-Managements entwickelten Maßnahmen und Verfahren zur Risiko-Minderung implementiert werden und die Implementierung nachvollziehbar dokumentiert wird. Außerdem sind sie in den meisten Fällen auch daran beteiligt, die Maßnahmen zur Risiko-Minderung zu erarbeiten, Messwerte für Risiken festzulegen (z.B. indem KPI dafür definiert werden) und das Monitoring für die Effizienz der implementierten Maßnahmen sicherzustellen. Da die Implementierung von Maßnahmen oft mehrere Bereiche des Unternehmens betrifft, für die unterschiedliche Verantwortlichkeiten bestehen, kann die Ownership für ein Risiko mehreren Verantwortlichen übertragen werden, die jeweils für die Implementierung von Schutzmaßnahmen und deren Monitoring in ihrem Verantwortungsbereich zuständig sind. Auch sind sie bei jedem Zyklus der Risiko-Bewertung beteiligt, wo sie den ISB dabei unterstützen, die aktuelle Höhe der Risiken (neu) einzuschätzen und die Effizienz bereits implementierter Kontrollen zu bewerten.

Insgesamt sorgen diese beiden Ownership-Verteilungen dafür, dass der ISB bei komplexen Aufgaben, wie Risiko-Bewertung oder Notfall-Management, Unterstützung von genau jenen Personen im Unternehmen bekommt, die über die notwendigen Informationen, Kompetenzen und Befugnisse verfügen. Er muss sich "nur" noch darum kümmern, dass die Informationen der Owner zusammenfließen und erfasst und bewertet werden. Gleichzeitig wird damit die Awareness für Sicherheitsthemen bei den Ownern verbessert, weil sie sich mit den Risiken ihrer Assets oder zu den Maßnahmen, die sie implementieren, auseinandersetzen müssen. Durch die regelmäßige Wiederholung der Risiko-Bewertung, wird ihnen dieses Thema automatisch immer wieder ins Bewusstsein gerufen.

Der Sicherheitsbericht

Dass ein regelmäßiger Security Report an das Management des Unternehmens geht, versteht sich in einem ISMS eigentlich von selbst. Üblicherweise sollte das quartalsweise geschehen. Dieser Bericht wird in manchen Unternehmen als "geheim" klassifiziert und nur der Führungsebene zugänglich gemacht. Ich empfehle jedoch, dass der Sicherheitsbericht aus 2 Teilen bestehen sollte. Der eine Teil wird als "intern" eingestuft, und kann von allen Mitarbeitern eingesehen werden. Dieser sollte vor allem einen Überblick über den Stand der Informationssicherheit geben und die kritischen Risiken, die Bereiche, in denen sie sich auswirken können, und die geplanten Schutzmaßnahmen aufzeigen. Der zweite Teil kann dann mit mehr Details nur für das Management eingeschränkt werden und auf Themen wie Finanzen u.ä. eingehen, was nicht für die Allgemeinheit bestimmt ist. Der interne Teil wird jedoch auch durch das Management freigegeben, damit dort keine Informationen enthalten sind, die die Geschäftsführung selbst als geheim einstuft.

Wie weiter oben bereits gesagt, sollten auch Berichte, die die Schwachstellen des Unternehmens aufzeigen, für alle Mitarbeiter einsehbar sein, damit diese in ihrem Verantwortungsbereich proaktiv gegen Risiken und Schwachstellen vorgehen oder wenigstens ein Auge auf sie haben können. Es ist unsinnig immer erst darauf zu warten, dass das Risikomanagement ein bestimmtes Problem adressiert. Wichtig ist stattdessen, dass man dafür sorgt, dass die notwendigen Informationen über die Implementierung von Maßnahmen immer erfasst und dem ISB übermittelt werden. Es sollte also ein Prozess geschaffen und den Mitarbeitern vermittelt werden, der sicherstellt, dass ein Mitarbeiter, der ein Problem aus dem Sicherheitsbericht in seinem Bereich beheben möchte, sich im ersten Schritt an den ISB wendet und ihn über die geplante Maßnahme informiert. So bekommt der ISB die Möglichkeit, auf notwendige Dokumentations-/Nachweispflichten hinzuweisen und den Fortschritt der Implementierung zu tracken, damit dies in die Reifegrad-Bewertung des ISMS einfließen kann.

Sicherheits-Assistenten

Der ISB sollte immer ein fester Bestandteil von Planungs-Meetings sein, damit die Informationssicherheit bereits bei der Planung von Projekten oder Veränderungen berücksichtigt wird. Ab einer bestimmten Unternehmensgröße oder Komplexität in dessen Organisation, wird es für den ISB jedoch immer schwieriger, seine Vorgaben in die Teams und Fachbereiche zu tragen und an allen solchen Meetings teilzunehmen. Vor allem die Awareness bleibt schnell auf der Strecke, wenn die Security-Sicht nicht zumindest bei den strategischen Meetings, z.B. zum Start neuer Projekte oder dem Umbau von Abteilungen, eingebracht wird.

Um dieses Problem zu lösen, kann es hilfreich sein, eine Person in jedem Team zum Sicherheits-Assistenten zu benennen. Diese werden vom ISB darin geschult, welche Informationen sie an ihn übermitteln müssen, wie sie mögliche Risiken in Projekten selbst erkennen können und wann sie den ISB involvieren müssen, damit Risiken bereits in der Planung beachtet und im Projektverlauf gemildert oder behoben werden können. Auch wenn die so geschaffenen Security-Mitarbeiter keine Experten in der Informationssicherheit sind, werden sie durch den regelmäßigen Austausch mit dem ISB dennoch das Thema Sicherheit mehr im Fokus behalten. Sie können darauf hinwirken, dass der ISB immer rechtzeitig involviert wird, wenn durch Veränderungen im Unternehmen oder durch neue Projekte mögliche neue Risiken entstehen, oder wenn bereits bekannte Risiken möglicherweise neue Angriffsvektoren erhalten. Und erfahrungsgemäß lernen sie im Laufe der Zeit auch einiges über Informationssicherheit und tragen dieses Wissen in ihre Teams. Vor allem aber sind sie ein Sprachrohr des ISB in ihren Teams und sorgen dafür, dass der ISB nur dann hinzugezogen werden muss, wenn sein Wissen wirklich benötigt wird. Das spart dem ISB so manches unnötige Meeting. Gleichzeitig sorgen sie dafür, dass die für das ISMS benötigten Nachweise aus ihrem Fachbereich an den ISB übermittelt werden.

Schlusswort

Man sieht also, dass es verschiedene Wege gibt, um ein ISMS im Unternehmen sichtbar zu machen. Der effizienteste Weg ist die Einbindung der Stakeholder in die Definition und Implementierung von Maßnahmen / Kontrollen. In Verbindung mit den Prüfverfahren und Audits für das ISMS, die der ISB im Rahmen seiner Aufgaben regelmäßig durchführt, wird das Thema Informationssicherheit so immer wieder im gesamten Unternehmen präsent gemacht. Besonders gut funktioniert das, wenn man die aufgezeigten Wege kombiniert. Dann werden fast schon automatisch verschiedene Kommunikationspunkte geschaffen, an denen der ISB die Möglichkeit hat, Hintergrundwissen an die Mitarbeiter zu vermitteln und so mehr Verständnis für Sicherheitsmaßnahmen zu schaffen.

Wichtig ist vor allem, dass ein ISMS nicht von oben diktiert wird. Es funktioniert viel besser, wenn die Mitarbeiter frühzeitig in den Aufbau des ISMS eingebunden werden, um die vorhandenen Geschäftsprozesse und Verantwortlichkeiten bei der Implementierung von Sicherheitsmaßnahmen ausreichend zu berücksichtigen und bereits vorhandene Strukturen effizient weiterzuverwenden.

Es liegt allerdings in der Natur eines ISMS, dass es jede Menge Vorgaben machen muss. Diese werden leichter von den Mitarbeitern akzeptiert, wenn sie oder jemand, der ihre Interessen vertritt, in die Entwicklung der entsprechenden Richtlinien und Verfahren eingebunden ist. Auch sinkt der Widerstand gegen Vorgaben, wenn diese in der Praxis möglichst geringe Auswirkungen haben, z.B. indem vorhandene Prozesse angepasst werden, anstatt neue Prozesse zu schaffen.

Die Erfahrung zeigt jedoch auch, dass die Implementierung eines ISMS dann am besten funktioniert, wenn das Top-Management im Unternehmen voll dahintersteht und den ISB bei seinen Aufgaben so gut wie möglich unterstützt. Wird die Rolle des ISB zusätzlich abteilungsübergreifend und direkt unter dem C-Level angesiedelt, hat er auch die notwendigen Befugnisse, um eine effiziente Implementierung des ISMS in direkter Absprache mit den Bereichsverantwortlichen umzusetzen.

Der einfachste Weg ein ISMS zu einem gelebten Teil der Firmenkultur zu machen, führt über die aktive Einbindung aller Parteien in dessen Aufbau und die zugehörigen Prozesse. Widerstände bei den Mitarbeitern löst man am ehesten auf, indem man sie abholt und ihnen das notwendige Wissen vermittelt, um ein Verständnis für die neuen Anforderungen aufzubauen.