ISO 27001: Ist die Zertifizierung für Informationssicherheit die Mühe wert?

Die IT-Sicherheit war in der Theorie schon immer wichtig, wurde in der Praxis aber lange Zeit stiefmütterlich behandelt. Seit einigen Jahren steigt nun der Stellenwert von Informationssicherheit im öffentlichen Diskurs und in Unternehmen. Datenverluste, menschliche Fehler und Cyberattacken gehören zum Arbeitsalltag. Vor allem letztere nehmen verstärkt zu. Hacker überlegen sich immer neue ausgefeiltere Strategien, um widerrechtlich an fremde Daten zu gelangen. Gleichzeitig wachsen in unserer zunehmend digitalisierten Welt die Datenmenge und die Abhängigkeit von digitalen Prozessen rapide.

Wie können Unternehmen da noch sicher sein, dass ihre Informationen geschützt sind und sie dabei nicht den Überblick verlieren? Abhilfe schafft die ISO 27001, die internationale Norm für Informationssicherheitsmanagementsysteme (kurz: ISMS). Sie legt Maßnahmen zugrunde, mit denen Unternehmen die Sicherheit ihrer Informationswerte verbessern können. Zu diesen Informationswerten zählen zum Beispiel materielle Werte, Serverdaten, Daten von Kund:innen und das Wissen der Mitarbeitenden.

Es lässt sich schnell erkennen, dass die ISO 27001 Zertifizierung einen recht großen Aufwand bedeutet. Allerdings bringt sie neben dem Minimieren von Risiken der Informationssicherheit weitere entscheidende Vorteile mit sich. Unser Kollege Martin Dolhs, Informationssicherheitsbeauftragter in der HEC, spricht im Interview über seine Erfahrungen, die er im Zertifizierungsprozess der HEC gesammelt hat: Wie hoch ist der Aufwand? Wie läuft der Prozess konkret ab? Was passiert bei Lücken im ISMS? Wie passt ein ISMS in die Projektarbeit und zu agilen Methoden? Wie haben wir die Mitarbeitenden mitgenommen?

Martin Dolhs: Wir haben einerseits überlegt, wie wir die Sicherheit bei uns im Unternehmen verbessern können. Andererseits haben wir erwartet, dass die Zertifizierung in Zukunft von Kunden vermehrt angefragt werden könnte. Vor über vier Jahren hat unser Prozess begonnen. Zu dieser Zeit haben wir bemerkt, dass der Stellenwert von Informationssicherheit steigt. Inzwischen liest man beinahe jeden Tag in den Medien von Hackerangriffen auf Unternehmen. Auch sind die Gesetzgebung und mit ihr die Sicherheitsanforderungen weiter vorangeschritten, wodurch vor allem Unternehmen mit kritischer Infrastruktur, wie beispielsweise Energieversorger betroffen sind. Da wir als Lieferanten indirekt auch davon betroffen sind, haben wir uns entschieden, nicht einfach nur so Informationssicherheit zu machen, sondern uns zertifizieren zu lassen. Wir wollen mit dem Zertifikat zeigen, dass wir alles tun, um die Informationssicherheit in der HEC kontinuierlich zu verbessern.

Martin Dolhs: Die eigentliche Zertifizierung ist aufwändig. Das ist aber der kleinste Teil, da die Auditoren insgesamt nur etwa 8 Tage für die ISO 27001 und ISO 9001 vor Ort im Unternehmen sind. Den größeren Aufwand macht die Vorbereitung aus. Das heißt, die Prozesse zu definieren, zu dokumentieren, letztendlich auch alle Mitarbeitenden zu schulen, ihr Bewusstsein zu schärfen und vor allem zu erreichen, dass die Maßnahmen tatsächlich umgesetzt werden. Dafür sollte man mindestens ein Jahr Zeit einplanen.

Außerdem ist die Norm sehr breit aufgestellt. Sie geht von der Sicherheit der Verkabelungen über das Notfallmanagement und das Personalwesen bis natürlich hin zu Themen, die die IT betreffen. Daher lässt man sich idealerweise vorweg noch schulen, um die Norm zu verstehen. In den Folgejahren nach dem ersten Audit und der Zertifikatsvergabe ist der Zeitaufwand dann aber wesentlich geringer.

Martin Dolhs: Wir hatten einen externen Berater, der uns geholfen hat, die ersten Schritte zu gehen. Dadurch standen wir nicht allein vor der umfangreichen Vorbereitung.

Die Norm verlangt, dass man risikobasiert arbeitet, um die Informationswerte des Unternehmens zu schützen. Um auszumachen, wo potenzielle Risiken bestehen, mussten wir zuerst einmal diese Informationswerte feststellen. Das kann Hardware sein, aber auch beispielsweise das Wissen in den Köpfen der Mitarbeitenden. Wir haben sie auf einer Liste zusammengetragen und ihnen die jeweilig möglichen Risiken zugeordnet. Anschließend haben wir überlegt, wie wir diese einzelnen Risiken abmildern oder akzeptieren können, sofern sie nicht zu groß sind.

Dann haben wir die Prozesse beschrieben. Damit meine ich, wie wir eine stetige Verbesserung schaffen, wie wir Schulungen halten, wie wir alles dokumentieren, wie wir die Risiken und die von ihnen abgeleiteten Maßnahmen nachverfolgen werden. Dabei entstand ein großer Blumenstrauß an Dingen, die es zu berücksichtigen gilt. Da es in der Norm knapp 100 dieser Controls gibt, kostete das viel Zeit. Einzelne Controls weglassen darf man nur in Ausnahmefällen und mit schlüssiger Begründung.

Martin Dolhs: Die Prozesse zu beschreiben, ist natürlich eine Sache, aber dass sie funktionieren, eine ganz andere. Wir mussten die Kolleginnen und Kollegen entsprechend schulen, die neu entwickelten Prozesse etablieren, damit sie auch wirklich gelebt werden, und Nachweise darüber sammeln. Bedeutet genauer: Nachweise über die tatsächlich stattgefundenen Schulungen und internen Audits, mit denen wir überprüft haben, ob die Prozesse funktionieren.

Als wir dann sicher sein konnten, dass unser Informationssicherheitsmanagementsystem funktionierte, haben wir uns um einen externen Auditor bemüht. Dieser hat bei uns im Unternehmen zunächst die abgelegten Dokumente geprüft. Anschließend hat er in die Prozesse reingeschaut, Interviews mit beispielsweise der IT und der HR geführt und sich Nachweise zeigen lassen. Da bei uns alles in Ordnung war, haben wir nach diesem Audit schließlich unser Zertifikat über die ISO 27001 erhalten.

Allerdings können wir uns darauf nicht ausruhen, da einmal im Jahr ein Überprüfungsaudit stattfindet. Die Norm fordert eben stetige Verbesserung, um die Informationssicherheit immer noch ein bisschen höher zu treiben.

Martin Dolhs: Das kommt auf die Lücken an. Wenn eine Hauptabweichung festgestellt wird, ist das ein K.O.-Kriterium für die Zertifizierung und man erhält eine Nachfrist zur Behebung oder das Audit kann sogar abgebrochen werden. Das passiert zum Beispiel, wenn man gar keine Risikobehandlung durchgeführt hat. Treten aber nur kleinere Abweichungen auf, die heilbar sind, hat man eine gewisse Zeit, den Mangel zu beheben und darüber einen Nachweis zu erbringen. Manchmal kann auch eine Nachprüfung notwendig sein. Das Zertifikat würde man dennoch erhalten.

Letztlich ist es aber nicht die Aufgabe des Auditors, Fehler zu finden, sondern die erbrachten Nachweise zur Erfüllung der Norm zu prüfen.

Martin Dolhs: In der Projektarbeit haben wir schon viel richtig gemacht. Grundsätzlich ist es so, dass die Entwickler auf die Software, die sie bauen, stolz sein wollen. Also versuchen sie bereits aus ihrem eigenen Anspruch heraus gute Software zu entwickeln. Wir hatten schon vorher ein Ticketsystem und konnten nachweisen, welche Änderungen wir umsetzen.

Außerdem begleiten wir Projekte schon lange mit einer Art Checkliste, der DoPI (Definition of Project Initiation). Im agilen Prozess kam eine umfangreiche Dokumentation aber häufig zu kurz, da die Funktionsfähigkeit der Software an erster Stelle stand. Deshalb war es zentral, das Bewusstsein für Risiken in allen Teams tiefer zu verankern und den Blick für eine lückenlose Dokumentation zu schärfen. Dass wir die DoPI schon hatten, war praktisch. Wir konnten sie nutzen, erweitern und konkreter auf Informationssicherheit ausrichten.

Martin Dolhs: Nachdem wir formuliert hatten, was wir schon erfüllen, haben wir mit den Mitarbeitenden den Dialog gesucht und dadurch unseren ursprünglich geplanten Weg teilweise verändert. Wir haben versucht, möglichst viele Aspekte zu diskutieren. Die jeweiligen Verantwortlichen haben wir gefragt, was ihnen wichtig ist und was wir machen müssen, damit wir in allen Projekten und nicht bloß in einem Leuchtturmprojekt sichere Software entwickeln können.

Inzwischen bieten wir Projektchecks als eine Art internes Audit an. Dabei sprechen wir mit dem gesamten Team über das Projekt, weisen auf bestimmte Dinge hin, erklären, warum wir das so haben möchten und was die Vorteile sind. Wenn wir uns etwas überlegt haben, das alle für zu umständlich halten, dann versuchen wir es zu verbessern. Immer auf Verbesserung aus zu sein, ist ja auch der Sinn der Norm. Feedback ist dafür die beste Methode. Außerdem hoffen wir durch den gemeinsamen Austausch ein größeres Verständnis und mehr Akzeptanz zu schaffen.

Martin Dolhs: Ich war zu Anfang auch ein bisschen skeptisch, weil wir agil arbeiten. Agiles Arbeiten beruht auf Vertrauen. In der Norm kommt Vertrauen überhaupt nicht vor. Inzwischen sehe ich das aber ein bisschen anders.

Die Norm ist wie ein PDCA-Zyklus aufgebaut – plan, do, check, act. Man plant etwas, führt es aus, überprüft und verbessert es. So ein Zyklus ist im agilen Arbeiten auch üblich, nur kürzer. Wenn man wie wir nach Scrum arbeitet, ist es ein 14-Tages-Rhythmus. Auch dabei setzt man etwas Geplantes um, guckt, ob es funktioniert, und versucht es zu verbessern. Die Prozesse der Norm und von Scrum sind also grundsätzlich ähnlich. Auch bei Scrum gibt es ein Logbuch, in dem Entscheidungen dokumentiert werden. In der Norm sind allerdings mehr Verwaltung und Nachweise notwendig. Ich denke, die ISO 27001 auf agiles Arbeiten anzuwenden, ist daher kein Widerspruch.

Martin Dolhs: Wir werden weiterhin daran arbeiten, die Awareness im gesamten Team zu stärken. Das ist notwendig, um Angriffe auf Basis von Social Engineering vorzubeugen. Und mir liegt am Herzen, den Secure Software Development Lifecycle weiter zu verbessern, damit Sicherheit in allen Phasen gelebt wird, von der Konzeption über Entwicklung, Test, Deployment und Betrieb bis zur Stilllegung. Da sind wir schon ganz gut, aber da geht noch ein bisschen mehr.

Martin Dolhs: Wenn man sich zertifizieren lässt, sollte man einen Auditor haben, der sich mit dem entsprechenden Geschäftsfeld auskennt. Er kann besser auf die Besonderheiten des Unternehmens und der Branche eingehen und diese bei der Prüfung des ISMS berücksichtigen. Das erleichtert den Prozess der Zertifizierung ungemein.