goSecurity BLOG

Effizienz – eine (über-)lebenswichtige Notwendigkeit

Wer in seinem Business erfolgreich sein will, der versteht schnell, dass er dazu möglichst effizient sein muss. Es gilt das Motto: “Möglichst wenig Aufwand für möglichst viel Ertrag”. Deshalb kann man auch kaum ein Seminar zum Thema Effizienz besuchen, in dem nicht spätestens beim zweiten Themenblock das Pareto-Prinzip erklärt wird. Ich behaupte jetzt einfach mal, jeder Leser kennt dieses Prinzip, deshalb verzichte ich hier auf eine Erklärung.

Wer also sein Unternehmen auf Effizienz trimmen will, der verlangt auch nach Managementsystemen, welche diese unterstützen. Eine logische Konsequenz ist somit auch, dass ein ISMS [1] Prozesse und Dokumentation effizient darstellen bzw. abdecken muss. Da winkt es wieder, das Pareto-Prinzip [2]. Aber jetzt sind wir bereits bei der Titelfrage: Darf man das hier überhaupt anwenden? Reichen 80 % Umsetzungsgrad bei einem ISMS?
Und welche 20 % darf man vernachlässigen? Kann man diese überhaupt so konkret definieren?

Wie sehen ISMS-Projekte in der Realität aus?

Aufgrund meiner Tätigkeit als Security Consultant, ISO-Auditor und CISO as a Service [3] hatte ich schon Einsicht in mehrere Dutzend ISMS-Aufbauprojekte. Und sie alle hatten – mit wenigen Ausnahmen – folgende Eigenheiten gemeinsam:

• Hochmotivierter Start des Projekts, doch meist nach wenigen Monaten ausgebremst durch das Tagesgeschäft

• Geplante Laufzeit von max. 12 Monaten, in der Realität dann ausgedehnt auf 2–3 Jahre

• Oft schon von Beginn weg zu wenige Ressourcen, teilweise sogar eine „One-Man-Show“ seitens der Kunden

Verstärkt werden diese Trends dann in der Regel noch dadurch, dass ein ISMS-Projekt in vielen Unternehmen wie ein IT-Projekt behandelt wird. Die Doppelbelegung der Rollen Leiter IT und CISO durch dieselbe Person ist leider in 9 von 10 Fällen Realität. Dies ist zwar irgendwie nachvollziehbar, denn ein Grossteil der Informationssicherheit wird für digitale Prozesse benötigt. Allerdings ist gerade in den heutigen Zeiten das IT-Team nur schon durch die Komplexität der zu betreuenden Systeme und Applikationen am Limit. Wo soll da noch Zeit herkommen für das Schreiben der Richtlinien, Dokumentationen und der Definition der benötigten Prozesse?

Und aus dieser Problematik entsteht sie wieder, die Frage: Reichen denn nicht 80 % Erfüllungsgrad aus? Bekanntlich sind ja die letzten 20 % der beschwerlichste Teil des Weges …

Was fordert die Norm ISO 27001 wirklich?

Da das Ziel der meisten ISMS-Projekte eine Zertifizierung nach ISO 27001 [4] ist, müssen wir jetzt zwingend einen Blick in diese Norm werfen. Wir finden dort in den Kapiteln 4–10 den normativen Teil, also alles „Muss-Anforderungen“ (oder, wie ich persönlich gerne ergänze, an das Management gerichtete Anforderungen). Diese müssen alle zwingend für den Erhalt eines Zertifikats erfüllt werden. Dann gibt es den Anhang, in dem insgesamt 93 Massnahmen (gegliedert in organisatorische, personenbezogene, physische und technologische Massnahmen) zu finden sind. Diese Massnahmen dienen der Mitigation der Risiken, und gemäss Kapitel 6.1.3 muss genau deklariert werden, welche Massnahmen wie – oder eben nicht – angewendet werden. In der begleitenden Norm ISO 27002 [5] wird dann erklärt, wie diese Massnahmen eingeführt bzw. umgesetzt werden können. Und jetzt wird es spannend. Wir werfen kurz einen Blick in das Kapitel 0.1 (ja, das gibt es) der Norm ISO 27002. Und da finden wir dann Hinweise wie:

• „… Die Einführung einer Reihe geeigneter Sicherheitsmassnahmen, darunter Richtlinien, Regeln, Prozesse, Verfahren, Organisationsstrukturen sowie Software- und Hardwarefunktionen, sorgt für Informationssicherheit …“

• „… Ein Informationssicherheitsmanagementsystem (ISMS), wie in ISO/IEC 27001 näher beschrieben, verfolgt eine ganzheitliche, koordinierte Betrachtung der Risiken in der Informationssicherheit einer Organisation …“

• „… Die Sicherheitsstufe, die allein durch technische Massnahmen erreicht werden kann, ist begrenzt und sollte durch geeignete Managementaktivitäten und organisatorische Prozesse unterstützt werden …“

• „… Ein geeignetes, angemessenes und wirksames Managementsystem für die Informationssicherheit bietet der Leitung der Organisation und anderen interessierten Parteien die Vertrauenswürdigkeit, dass ihre Informationen und andere damit verbundenen Werte angemessen sicher und vor Bedrohungen und Schäden geschützt sind …“

Die Worte „geeignet„, „angemessen“ und „wirksam“ begegnen einem beim Studium der Norm immer wieder, und schnell wird klar, dass bei fast allen Themen genau eine Vorgehensweise die richtige ist: risikobasiert!

Es gibt also nicht ein einzelnes, richtiges Projektverfahren, um ein ISMS anhand ISO 27001 aufzubauen. Sondern: Beim Schreiben jeder Richtlinie, beim Optimieren jedes Prozesses und beim Definieren jeder Schutzmassnahme sollte immer zuerst geprüft werden: Wie hoch ist das zugrundeliegende Risiko für dieses Unternehmen? Wie hoch ist ein mögliches Schadenspotenzial? Wie hoch ist die Wahrscheinlichkeit, dass genau dieses Risiko eintritt? Und daraus werden dann „geeignete“, „angemessene“ und „wirksame“ Methoden abgeleitet und umgesetzt.

Merke: Jedes ISMS, das nicht mit diesem Grundgedanken aufgebaut und implementiert wird, ist im schlimmsten Fall wirkungslos!

Das Pareto-Prinzip im ISMS-Kontext konkretisiert

Jetzt aber nochmals einen Schritt zurück. Das obige Kapitel ist verstanden, aber wir stellen nochmals die Frage: Darf ich jetzt beim Aufbau des ISMS das Pareto-Prinzip anwenden – ja oder nein?

Die Antwort lautet: jein. Oder anders ausgedrückt: Wenn ich einfach Themen weglasse, die mir von Beginn weg zu aufwändig erscheinen, dann klar nein. Wenn ich aber im Laufe der verschiedenen Risiko-Betrachtungen Themengebiete entdecke, bei denen die Risiken für mein Unternehmen tendenziell gering sind, und ich mich da entscheide, nur die grundsätzlichen Schutzmassnahmen zu implementieren, dann ja.

Tatsächlich gibt es bei genauerer Betrachtung einige „80/20“-Hebel im ISMS:

Bei technischen Massnahmen:

• Exponierte Zugänge durch MFA (Multi-Factor-Authentication) schützen → das reduziert die Angriffsfläche schon sehr stark.
• Ein gutes Patchmanagement → verhindert zu einem grossen Teil den Ausbruch bekannter Exploits.
• Ein gut durchdachtes Backup-Konzept → deckt schon mal die grundlegenden Ransomware-Risiken ab.

Bei organisatorischen Massnahmen:

• Klare Rollen & Verantwortlichkeiten verhindern einen „Overload“ der Organisation.
• Eine angemessene Klassifizierung von Informationen bewirkt viel beim Schutz beim Umgang mit den eigenen Informationen.

Bei Awareness-Themen:

• Regelmässige, gezielte und wirksame Schulungen reduzieren erwiesenermassen erfolgreiche Phishing-Angriffe signifikant.

Wir kommen somit zum Schluss: Das Pareto-Prinzip darf durchaus in einem ISMS-Projekt angewendet werden – aber nur risikobasiert und sinnvollerweise in Themengebieten, wo ich damit eine hervorragende Anfangswirkung erziele!

Wo das Pareto-Prinzip richtig gefährlich wird

Wir haben es bereits im oberen Kapitel erwähnt: Wenn ich einfach Themen weglasse, die mir von Beginn weg zu aufwändig erscheinen, dann gehe ich nicht nur unnötige Risiken ein, es kann auch wirklich gefährlich werden. Es könnte der Eindruck entstehen (u. a. auch beim Management), 80 % Erreichungsgrad heisst auch 80 % Sicherheit. Dem muss man aber klar widersprechen. Es könnte so nämlich passieren, dass ich ausgerechnet die 20 % vernachlässigt habe, bei denen die grösste Angriffsfläche für meine Organisation besteht, oder bei denen sich das simpelste Einfallstor für Angreifer oder Schadsoftware befindet.

Und falls es sich dabei um Themen wie Schutz vor Schadsoftware, tiefergehendes Lieferketten-Management, zeitnahes Patchmanagement oder auch eine vorzügliche Awareness aller Benutzer handelt, dann werden Informationssicherheits-Vorfälle oder sogar Datenverlust nicht lange auf sich warten lassen.

Ausserdem würde sich eine solche Vorgehensweise auch in den Audits negativ bemerkbar machen. Erfahrene Auditoren würden schnell feststellen, dass wichtige Themen ungenügend oder gar nicht behandelt wurden. Und dabei spielt es keine Rolle, ob die Unstimmigkeiten bei den Kapiteln 4–10 (Muss-Anforderungen) oder bei den Controls im Anhang (A.5–A.8) auftreten. Ist die Summe der gefundenen Nichtkonformitäten gross genug, wird eine kritische Nichtkonformität ausgesprochen, und es wird kein Zertifikat ausgestellt. Und was das bedeutet, ist auch klar: im schlimmsten Fall zurück auf Feld 1 und nochmals alle Themengebiete durchleuchten und optimieren. Was das für die Laufzeit und die Kosten eines solchen Projektes bedeutet, muss ich hier auch nicht erklären.

Der richtige Ansatz: Risikomanagement first, Pareto second

Ich möchte nochmals kurz die Norm ISO 27002 zitieren. In Kapitel 0.2 (ja, auch das gibt es) wird nochmals erwähnt, dass drei Hauptquellen für Anforderungen an die Informationssicherheit existieren, und die erste ist:

„Die Beurteilung von Risiken für die Organisation, unter Berücksichtigung der Unternehmensstrategie und der Geschäftsziele, ist die erste Hauptquelle für Anforderungen an die Informationssicherheit.” Dies kann durch eine informationssicherheitsspezifische Risikobeurteilung erleichtert oder unterstützt werden. Dies sollte zur Bestimmung der Massnahmen führen, die erforderlich sind, um sicherzustellen, dass das Restrisiko für die Organisation die Risikoannahmekriterien erfüllt.

Wenn ich also bei allen Entscheidungen, die ich im Rahmen eines ISMS-Projektes treffen muss, immer einen risikobasierten Ansatz verfolge, so werde ich meinen Fokus immer auf die Themengebiete oder Controls richten, die für mein Unternehmen die grösste Bedrohung darstellen. Daraus resultiert aber auch, dass es Themen und Controls geben wird, welche mein Unternehmen wenig bis gar nicht gefährden. Und da kann ich dann z. B. Controls aus dem Anhang auch begründet ausschliessen, oder ich kann Richtlinien schlanker erstellen, als es bei grösserem Risiko vielleicht nötig wäre (ein Praxisbeispiel: ein schlankes Technikraum-Reglement, wenn die Server ausgelagert wurden, vs. ein grösseres Serverraum-Reglement bei eigenem Datacenter).

Oder, ganz pragmatisch formuliert: Wenn ich beim ISMS-Aufbau risikobasiert vorgehe, dann habe ich das Pareto-Prinzip bereits in einem gewissen Sinn inkludiert.

Tipps aus der Praxis

Eines vorneweg: Gemäss meiner Erfahrung ist es nicht möglich, ein ISMS vom Start weg zu 100 % korrekt und vollständig aufzubauen. Dafür sind zu viele Unbekannte im Projekt verborgen, und der Aufwand, bestehende, womöglich tief verankerte Prozesse optimieren zu müssen, darf nicht unterschätzt werden.

Und eine zweite Lehre, die ich aus allen meinen Projekten gezogen habe: Zwar muss stets die Qualität stimmen, aber beim Vorantreiben eines ISMS-Projektes ist die Geschwindigkeit tatsächlich wichtiger, als gleich auf Anhieb für alles die perfekte Lösung in petto zu haben. Aus meiner Sicht ist es wichtig, “im Flow” zu bleiben. Längere Unterbrechungen, womöglich über Monate oder sogar über ein halbes Jahr hinweg, führen immer dazu, dass man viele Themen nochmals durchleuchten muss, und führen unweigerlich zu einer Verteuerung des Projektes.

Das Schöne an der Einführung eines ISMS nach ISO 27001 ist ja, und ich zitiere nochmals die Norm ISO 27002 aus Kapitel 0.1: „Es [dieses Dokument, also ISO 27002] soll als Referenz für die Bestimmung und Implementierung von Massnahmen zur Behandlung von Informationssicherheitsrisiken in einem Informationssicherheitsmanagementsystem (ISMS) auf der Grundlage von ISO/IEC 27001 verwendet werden.“ Die Verwendung des Wortes „Referenz“ macht nochmals klar: Ein ISMS muss in jedem Unternehmen individuell, risikobasiert und sowohl angemessen als auch wirksam aufgebaut werden. Aus diesem Grund kann ein Auditor übrigens auch keine Nichtkonformitäten in Bezug auf die Norm ISO 27002 aussprechen, da es sich eben nur um ein Referenzdokument, oder man könnte auch sagen, empfohlene Massnahmen, handelt.

Fazit

Langer Rede kurzer Sinn: Ja, der Aufbau eines ISMS darf theoretisch nach dem Pareto-Prinzip erfolgen, wenn dieses nicht zufällig gewählt, sondern im Sinne eines risikobasierten Ansatzes angewendet wird. Somit wäre es denkbar, dass in einem Zertifizierungs-Audit vielleicht nur 80 % möglicher Massnahmen aktiv und umgesetzt sind, oder der Maturitätsstatus der restlichen 20 % sich noch auf einem niedrigen Niveau befindet. Der kontinuierliche Verbesserungsprozess muss dann allerdings dafür sorgen, dass dies nicht so bleibt, sondern dass sich der Wirkungsgrad des ISMS stetig in Richtung 100 % bewegt.

Oder mit einem Fachbegriff aus der Geometrie erklärt: Der Erfüllungsgrad beim Aufbau und Betrieb eines ISMS wird immer einer Asymptote [6] ähneln. Eine Asymptote ist eine Linie, die sich der anderen annähert, ohne sie je zu berühren. Denn 100 % Erfüllungsgrad gibt es nicht – dafür sorgen die Menschen in jeder Unternehmung, globale oder lokale Marktbedingungen und nicht zuletzt die Bedrohungslage durch cyberkriminelle Organisationen.

Quellen

[1] ISMS: Information Security Management System

[2] Pareto-Prinzip:  Wikipedia – Paretoprinzip

[3] CISO as a Service (CISO aaS): Dieser Service bietet Unternehmen flexiblen, externen Zugriff auf erfahrene Sicherheitsexperten in dieser Position, ohne eine teure Festanstellung anbieten zu müssen. Dies ist vor allem für KMUs und Start-ups interessant, aber auch für Unternehmen, die sich zum ersten Mal strategisch mit dem Thema ISMS und CISO auseinandersetzen. Seit einiger Zeit wird auch gerne die Bezeichnung vCISO (virtual CISO) verwendet, wobei sich CISO aaS eher darauf bezieht, den Service eines CISO zu holen, im Gegensatz zum vCISO, wenn eine Person fix aus der Distanz agiert.

[4] ISO 27001: Standard für den Aufbau und Betrieb eines ISMS zur Steuerung von Informationssicherheit, Cybersicherheit und Datenschutz

[5] ISO 27002: Referenz für empfohlene Massnahmen zur Implementierung von ISO 27001

[6] Asymptote:  Wikipedia – Asymptote