Abseits von technischen Maßnahmen gibt es auch eine Reihe von organisatorischen Dingen, die sowohl zur Stärkung der IT-Sicherheit als auch zur Vorbereitung auf einen IT-Sicherheitsnotfall im Vorweg implementiert werden sollten. Deutlich grundlegender ist jedoch die Festlegung von Verantwortlichkeiten und Kompetenzen, welche nicht nur in der IT-Sicherheit eine wichtige Rolle spielen.
Der Inhalt im Überblick
Dem Chaos proaktiv begegnen
Die ISO 27001 Norm und die DSGVO bieten einige Empfehlungen zu konkreten organisatorischen Maßnahmen. Oft scheitert es nicht an deren Umsetzung, sondern an der generellen Unklarheit, wer dafür zuständig ist. Sind Verantwortlichkeiten und Kompetenzen nicht klar definiert, regieren schnell Chaos und Stillstand. Letztendlich führt dies zu Frust und schlechter Laune bei allen Beteiligten.
Ein Beispiel: Zur Einführung eines Informationssicherheitsmanagementsystems (ISMS) stellt die IT-Abteilung eine Plattform bereit. Das ISMS-Team nutzt diese, um das ISMS mit Leben zu füllen. Wie jedes IT-System muss auch dieses regelmäßig gewartet werden. Nun kann es passieren, dass die IT-Abteilung das IT-System als „ausgeliefert“ betrachtet und die Verantwortung hierfür nicht mehr bei sich sieht. Das sieht das ISMS-Team naturgemäß anders. Dafür macht die IT-Abteilung inhaltlich Änderungen zu den Teilen im ISMS, die sie betreffen. Hier sehen diese sich als zuständig und übergehen dabei die Verantwortlichen des ISMS-Teams. Das Chaos beginnt.
Bei einem IT-Notfall kann das die Situation nur verschlimmern. Sind die Rollen nicht klar verteilt, lässt sich die Behandlung des Vorfalls nicht optimal betreiben. Fehlt die Kompetenz, Entscheidungen zu treffen, wird wertvolle Zeit bis zu dessen Klärung verschwendet.
Die fehlende klare Benennung von Verantwortlichkeiten, Aufgaben und Kompetenzen schwächt die IT-Sicherheit, ist aber auch allgemein ein großes Problem bei Projekten oder der Zusammenarbeit verschiedener Stellen im Unternehmen. Dieses Grundproblem gilt es proaktiv anzugehen und z.B. bei der Definition von Prozessen diese schriftlich zu dokumentieren. Die Dokumentation von (internen) Prozessen hilft zugleich beim Aufbau eines funktionierenden Qualitätsmanagements.
Verantwortlichkeiten festlegen
Für jeden Prozess oder jedes Projekt sollte, idealerweise direkt bei der Einführung, ein Verantwortlicher benannt werden. Dabei gilt das Highlander-Prinzip: Es kann nur einen geben. Dieser Grundsatz ist jedoch nicht auf eine Person beschränkt. Es kann auch ein Team sein, das am Ende das Arbeitsergebnis zu verantworten hat. Grundsätzlich ist jedoch damit geregelt, wer Ansprechpartner ist und die finalen Entscheidungen treffen kann.
Das Problem mit der Verantwortung ist immer, dass man nicht nur für Erfolge, sondern auch für Probleme und Misserfolge verantwortlich ist. Durch eine klare Definition der Verantwortlichkeiten lassen sich Schwierigkeiten angehen und verbessern. Wurden ein problematisches IT-System oder ein Prozess identifiziert, der die Ziele der Informationssicherheit gefährdet, kann zusammen mit dem Verantwortlichen an der Verbesserung des aktuellen Zustandes gearbeitet werden. Dies spart Zeit und das kann letztendlich kritische Situationen vermeiden.
Es kommt leider oft vor, das IT-Systeme historisch gewachsen sind und „schon immer“ da waren. Wird eine kritische Sicherheitslücke publiziert, muss sich auch hier jemand verantwortlich fühlen, das System zu pflegen, auch wenn es sonst nie angefasst wird. Zur Identifikation solcher Systeme hilft ein Asset Management wie es z.B. die ISO 27001 vorsieht.
Kompetenzen definieren
Abgesehen von der Verantwortung sollten auch Kompetenzen definiert sein. Sind Projektmitarbeiter befugt, aufgrund von Sicherheitsmängeln das Projekt ggf. zu stoppen? Wer darf abhängig vom Risiko entscheiden, ob eine Nachbesserung notwendig ist, oder das Risiko getragen wird? Bei einem Sicherheitsvorfall ist es sinnvoll, verschiedene Szenarien und die daraus resultierenden Entscheidungen im Vorweg zu definieren. Für detaillierte Abwägungen von Chancen und Risiken bleibt im Notfall nicht genug Zeit.
Bei einem Angriff auf die IT-Systeme kann es schnell zu einem kritischen Punkt kommen, an welchem harte Entscheidungen getroffen werden müssen wie:
- Reichen die eigenen Ressourcen zur Bewältigung der Lage?
- Ab welchem Zeitpunkt werden Betroffene informiert?
- Ab wann muss der Webshop heruntergefahren werden?
- Wie wird mit den Mitarbeitern umgegangen? Müssen diese nach Hause geschickt werden?
- Wird die Verbindung ins Internet stillgelegt?
Die Kompetenz, für einzelne Bereiche oder das Unternehmen im Ganzen, Entscheidungen zu treffen, sollte vorher festgelegt sein. Dasselbe gilt für das Budget in solch einem Notfall und ebenfalls für die Weisungsbefugnis über Mitarbeiter. Der Krisenmanager ist in aller Regel nicht unbedingt Teil der Geschäftsführung oder eine Führungskraft, die über allen betroffenen Abteilungen steht. Somit müssen Kompetenzen ggf. auf andere Personen verschoben werden, um alle Maßnahmen abteilungsübergreifend koordinieren zu können. Letztendlich sollten die Absprachen auch Teil des Notfallkonzeptes sein.
Ein guter Plan muss getestet werden
Ein solches Konzept ist regelmäßig zu testen. Es ist wie mit einem Backup: Wenn beim Zurückspielen Probleme auftreten, bringt das Backup nichts. Um festzustellen, ob die Technik richtig funktioniert, muss diese getestet werden. Auch organisatorische Maßnahmen müssen regelmäßig auf ihre Angemessenheit, Anwendbarkeit und Wirkung hin evaluiert werden.
Ein fingierter IT-Sicherheitsvorfall lässt sich mittels externen Trainings oder unter Anleitung eines „Szenario-Leiters“ durchführen. Dieser gibt eine Ausgangssituation vor und die Beteiligten besprechen dann die notwendigen Maßnahmen. Mit weiteren Details zum theoretischen Angriffsgeschehen und gewonnenen Erkenntnissen wird das Szenario durchgespielt und im Anschluss evaluiert, ob das Ergebnis der Erwartung entspricht.
