Erfolgreich für den Ernstfall in der IT planen


Egal, ob Ihr Netzwerk löchrig wie Schweizer Käse oder sicher wie Fort Knox ist: Es gibt immer eine Möglichkeit für einen Angreifer, in Ihr Netzwerk einzudringen. Es lohnt sich daher, für den Ernstfall mit einem Notfallplan vorzusorgen und im Rahmen von an echten Szenarien orientierten Notfallübungen zu testen, ob Ihr Notfallplan den Praxistest besteht.

Ein IT-Notfall ist eine Situation, in der kein normaler Betrieb mehr möglich ist und rasch gehandelt werden muss. Mögliche Notfälle sind zum Beispiel ein von Ransomware betroffener Fileserver oder ein DDoS-Angriff auf einem Standort.

Immer mehr Unternehmen planen für den Notfall – das ergab eine Umfrage des Verbands der Internetwirtschaft (eco). Waren es 2018 noch 32 Prozent der befragten Unternehmen, hatten 2019 schon 57 Prozent Prozesse für den “Fall des Falles” definiert, und 80 Prozent bewerteten das Thema als “wichtig” oder “sehr wichtig”.

Einen ersten Ansatz kann der BSI-Standard 100-4 bieten, der jedoch sehr allgemein gehalten und in erster Linie für große Unternehmen und Organisationen geeignet. Es gibt jedoch einige Grundregeln, die Sie befolgen können, um rasch einen geeigneten Notfallplan für Ihr Unternehmen oder Ihre Organisation aufzubauen.

Alarmierung und Entscheidung

Im ersten Schritt legen Sie fest, wer einen Notfall melden kann. Wenn Sie ein Ticketsystem für User-Anfragen haben, können Sie es nutzen – achten Sie dabei allerdings darauf, dass nicht nur Ihre User, sondern auch Geschäftspartner oder Webseitenbesucher die Möglichkeit haben, einen Notfall zu melden.

Jedenfalls sollten Notfälle unmittelbar bearbeitet werden und nicht am Ende einer langen Schlange landen, und die Möglichkeit, Notfälle zu melden, sollte unkompliziert und auch bei Ausfällen erreichbar sein. Natürlich können Notfälle auch durch Monitoring-Systeme automatisch gemeldet werden.

Nach der Meldung muss es einen Entscheider geben, der festlegen kann: Notfall oder nicht? Grundsätzlich sollte ein solcher Entscheider jederzeit erreichbar sein – das heißt, dass Sie für den Fall von Urlaub oder Krankheit einen fachkompetenten Vertreter vorsehen müssen.

Wird entschieden, dass es sich nicht um einen Notfall handelt, kann die Anfrage als normale Support-Anfrage behandelt werden. Bei Feststellung des Notfalls beginnt der eigentliche Notfallplan.

Verschiedene Notfallpläne für verschiedene Systeme

Häufig betrifft ein Notfall nur ein System oder eine Gruppe miteinander verbundener Systeme. Es macht wenig Sinn, den Notfall für das gesamte Unternehmen oder die gesamte Organisation auszurufen, wenn nur ein Teil betroffen ist.

Grenzen Sie daher Teile Ihrer IT voneinander ab und legen Sie für jeden Teil einen eigenen Notfallplan fest. Dabei gilt: Notfallpläne machen nur Sinn, wenn bei einer längeren Störung Schäden drohen und eine rasche Reaktion diese Schäden verhindern oder zumindest erheblich reduzieren können.

Bei Systemen, die ohnehin kaum genutzt werden oder bei denen keine Eingriffsmöglichkeit für Sie besteht, müssen Sie keinen detaillierten Notfallplan aufstellen. Hier reicht es üblicherweise, einen “Plan B” zum Beispiel in Form eines anderen Anbieters oder einer provisorischen Lösung vorzuhalten.

Priorisierung

Um eine sinnvolle Priorisierung vornehmen zu können, sollten Sie im Vorhinein den Schadensverlauf betrachten, das heißt: Welcher Schaden entsteht wie lange nach Beginn des Notfalls?

Der Schadensverlauf für den Ausfall des zentralen Produktionsservers bei einem Automobilzulieferer. Schäden (y-Achse) sind in Tausend Euro angegeben, die Ausfallzeit (x-Achse) in Stunden.

Der Schadensverlauf für den Ausfall des zentralen Produktionsservers bei einem Automobilzulieferer. Schäden (y-Achse) sind in Tausend Euro angegeben, die Ausfallzeit (x-Achse) in Stunden.
(Bild: Syret)

Die nebenstehende Grafik zeigt den Schadensverlauf für den Ausfall des zentralen Produktionsservers bei einem Automobilzulieferer. Schäden (y-Achse) sind in Tausend Euro angegeben, die Ausfallzeit (x-Achse) in Stunden.

Wie zu sehen ist, halten sich die Schaden in den ersten acht Stunden in Grenzen, da die Produktion durch Datenpuffer im Wesentlichen unbehindert weiterläuft, jedoch ein Eingreifen nur beschränkt und manuell möglich ist. Nach diesen acht Stunden stoppt die Produktion. Da ein gewisser Lagerbestand vorhanden ist, müssen erst nach 24 Stunden Produktionsausfall Pönalen gezahlt werden, die einen erheblichen Schaden verursachen.

Der Notfallplan für den zentralen Produktionsserver sollte also vorsehen, möglichst nach acht Stunden den Normalbetrieb wiederherzustellen, wenn das nicht möglich sein sollte, dann zumindest nach 24 Stunden.

Beim gleichzeitigen Ausfall mehrerer Systeme haben Systeme, bei denen hohe Schäden bereits nach vier Stunden eintreten – zum Beispiel einzelne Produktionsrechner – Priorität vor dem Produktionsserver.

Die Arbeitsplätze der Konstrukteure, bei denen beim Ausfall erst nach einer Woche nennenswerte Schäden auftreten, müssen hingegen warten – sollte es aber den Verdacht auf Datenabfluss an die Konkurrenz geben, wo die Schäden unmittelbar auftreten, haben sie Priorität.

Das Notfallteam

Um den Notfall zu behandeln, sollten Sie im Voraus für jeden Teil der IT ein Notfallteam zusammenstellen, das aus allen für diese Systeme zuständigen Mitarbeitern und Externen, wenn notwendig, besteht.

Das Notfallteam wird durch den Entscheider zusammengerufen, der auch die Priorisierung anhand des Schadensverlaufs übernimmt.

Dauert der Notfall länger, ist für eine Ablösung zu sorgen. Erfahrungsgemäß ist nach acht Stunden in einer stressigen Situation keine Konzentrationsfähigkeit mehr vorhanden und das Risiko für schwere Fehler steigt rapide.

Da bei einem Notfall auch der E-Mail-Server oder die Telefonanlage ausfallen kann, empfiehlt es sich, im Vorhinein Handynummern auszutauschen oder andere Kommunikationswege parat zu halten, um die Kommunikation zu gewährleisten.

Das Notfallteam muss nicht an einem Ort sitzen, sollte aber auch beim Ausfall von Internetverbindungen handlungsfähig bleiben.

Die Vorgehensweise im Notfall

Der Notfallplan sollte für jeden Teil der IT eine Festlegung enthalten, was zu tun ist, wie dies zu tun ist und welche Personen herangezogen werden müssen.

Beispiel für einen Notfallplan für den zentralen Fileserver im Fall eines Ausfalls durch Ransomware.

Beispiel für einen Notfallplan für den zentralen Fileserver im Fall eines Ausfalls durch Ransomware.
(Bild: Syret)

Beispielsweise könnte ein Notfallplan für den zentralen Fileserver im Fall eines Ausfalls durch Ransomware aussehen wie in der Grafik links. Dieser Notfallplan muss im Ernstfall nur noch durch das Notfallteam abgearbeitet werden, wobei natürlich im Einzelfall Abweichungen möglich sind.

Ende des Notfalls

Ist der Normalbetrieb zumindest teilweise wiederhergestellt, kann der Notfall beendet werden. Sie sollten dabei einen Schwellenwert festlegen, ab dem es sich nicht mehr um einen Notfall handelt, auch wenn noch Restarbeiten verbleiben. Diese können anschließend ähnlich wie normale Support-Arbeiten erledigt werden.

Die Verantwortung für die Beendigung eines Notfalls liegt wiederum beim Entscheider.

Notfallübungen

Um den Notfallplan in der Praxis zu testen, sollten Sie regelmäßige Notfallübungen vornehmen. Ziehen Sie dazu einen Moderator bei, der ein Szenario entwickelt, das das Notfallteam im Voraus nicht kennt, sondern – wie in einem echten Notfall – erst herausfinden muss.

Eine Übung kann sich auf Kommunikationswege und Prozesse beschränken, aufschlussreicher ist es allerdings, auch technische Vorgänge wie die Wiederherstellung aus einem Backup zu proben.

Um eine Auswertung der Notfallübung und eine etwaige Verbesserung des Notfallplans zu ermöglichen, sollten Sie einen Protokollführer beteiligen, der nicht Teil des Notfallteams ist, aber das Szenario, alle getroffenen Entscheidungen und alle Vorgänge protokolliert. Auf der Basis seines Protokolls können Sie in der Nachbesprechung der Notfallplan bewerten und anpassen.

Über den Autor: Marian Kogler ist Geschäftsführer der Syret GmbH, einem deutschlandweit tätigen Beratungsunternehmen aus Halle an der Saale, das sich mit IT-Sicherheit und IT-Forensik beschäftigt. Unter anderem hat er Notfallpläne für Unternehmen aus verschiedenen Branchen entwickelt und führt regelmäßig als Moderator Notfallübungen durch.





Source link

Related posts