Notfallplan und Notfallmanagement Richtiges Verhalten bei einem IT-Sicherheitsvorfall

Irgendwann trifft es jedes Unternehmen, und jede Organisation. Wie man so schön sagt ist es „Nicht die Frage ob, sondern wann“ ein Sicherheitsproblem in der IT zu einem tatsächlichen Vorfall wird. Der richtige Umgang ist entscheidend, ein planvolles Vorgehen unabdingbar. Jedes Unternehmen sollte einen Notfallplan bereithalten. Wir zeigen empfohlene Best Practice, die im Ernstfall weiterhelfen.

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

FTAPI Software GmbH

Arctic Wolf Networks Germany GmbH

SolarWinds EMEA Headquarters

Dass die Zahl der Sicherheitsvorfälle steigt und steigt, bestätigt auch das BSI in seinen Lageberichten. Das ist umso bedenklicher, wenn man betrachtet, wie viel Zeit und Aufwand mit der Abwehr beziehungsweise Prävention als Maßnahmen zum Schutz vor Sicherheitsvorfällen betrieben wird. Jedes Unternehmen sollte einen Notfallplan bereithalten. Doch im Folgenden geht es vielmehr um empfohlene Best Practice, was zu tun ist, wenn etwas geschehen ist oder gerade geschieht. Mit dem Ziel, Auswirkungen zu vermeiden, die durch Beeinträchtigung von Geschäftsfunktionen einen großen Schaden anrichten und die Informationssicherheit erheblich verschlechtern können.

Glücklicherweise gibt es Frameworks, die sich mit diesen Themen befassen – allen voran bei uns in Deutschland das BSI, aber auch das National Institute of Standards and Technology (NIST) sowie das SANS-Institut haben dazu einiges verfasst. Bei SANS sind es im „Incidents Handler's Handbook“ die Abschnitte Identification, Containment, Eradication und Recovery, interessant, die entsprechenden Funktionen bei NIST sind Detect, Respond, Recover.

Was tun im IT-Notfall?

IT-Notfallkarte für KMU

Sofortmaßnahmen

Sobald ein Vorfall bemerkt wird müssen, im Idealfall durch ein geeignetes Werkzeug, wie ein SIEM, Maßnahmen durchgeführt werden. Tatsächlich kommt es hier nicht auf Details an, sondern auf Geschwindigkeit. In der IT kennt man generell MTTR, “mean time to resolve”, in der Security kommt MTTD noch davor, die “mean time to detect”. Die Sofortmaßnahmen sitzen dazwischen und sind, je nach Situation, dem Notausschalter an einer Industriemaschine gleichzusetzen. Was immer gerade passiert, muss gestoppt werden und im schlimmsten Fall heißt das „lock-down“: eine komplette Plattform herunterfahren, zumindest jedoch die Kommunikation mit dem Angreifer unterbrechen.

Im Gefahrenfall herrscht oft Unsicherheit, jedoch ermöglicht eine verzögerte Reaktion häufig einen ungewollten Datenabfluss. Schnelles Handeln ist deshalb unerlässlich. Im Anschluss müssen die notwendigen Personen wie der IT-Sicherheitsbeauftragte oder die Geschäftsführung benachrichtigt werden. Eine schnelle Reaktion kann mit Glück sogar bei der Behandlung helfen, bevor tatsächlicher Schaden entstanden ist. Manche Organisationen verfügen über ausreichend Kompetenz und geeignete Werkzeuge wie Echtzeit-Forensik und Automatismen, bei denen die Sofortmaßnahmen von Software gesteuert sind.

Ursachen finden und Nachforschung betreiben

Nachdem die akute Situation beseitigt und unberechtigter Zugriff unterbunden wurde, steht die Suche nach den Ursachen sowie das Ermessen des entstandenen Schadens an. Die jeweiligen Ergebnisse entscheiden über weitere Schritte.

Einige Fragen, die jetzt helfen sind: Wie wurde die Perimeterabsicherung überwunden? Wurde eine bisher unbekannte Schwachstelle einer Software ausgenutzt? Gab es in der letzten Zeit Veränderungen in der IT, wie neue Hardware oder Software? Warum haben alle Präventivmaßnahmen versagt? Warum hat es Zeitraum X gedauert, bis es bemerkt worden ist? Ich schlage noch eine weitere, brisante Frage vor: Hat jemand in der letzten Zeit das Unternehmen „in gegenseitigem Einverständnis“ verlassen? Haben Sie es mit dem Schadensrisiko Innentäter oder kurzfristig im Unternehmen tätigen Fremdpersonal zu tun, welches über volle physische und virtuelle Zugangsmöglichkeiten zu Räumlichkeiten, Netzwerken und Datenbanken im Unternehmen verfügt und zugleich mit den notwendigen sozialen Kontaktmöglichkeiten ausgestattet sind?

Nachdem die Ursachen identifiziert worden sind, kann der Schaden ermittelt werden. Auf welche Ressourcen wurde zugegriffen? Welche Daten sind nach außen gelangt? Wurden Daten gelöscht? Schwieriger festzustellen ist, auf welche Daten generell zugegriffen worden ist und darüber hinaus, ob diese verändert wurden. Wenn nicht vorab ein Werkzeug mit File Integrity Monitoring eingesetzt worden ist, kann man den tatsächlichen Zugriff nicht einwandfrei identifizieren. In Pressemitteilungen liest man dann von „potenziellem Zugriff (auf Millionen von Kundendaten).“

Im Zweifelsfall ist der Schaden vermutlich grösser als zuerst angenommen. Jeder, der sich mit Security beschäftigt, kennt das Konzept des „honey pots“ zur Entlarvung krimineller Cyber- Aktivitäten, aber auch Angreifer nutzen ähnliche Ideen, um Spuren zu verwischen. Hierbei ist es wichtig zu erwähnen, dass das Nachforschen passiv zu erfolgen hat. Es dürfen zum jetzigen Zeitpunkt keine Veränderungen am Ist-Zustand durchgeführt werden.

Wiederherstellung / Recovery

In den meisten Fällen wird von diesem Zeitpunkt an zweigleisig gefahren: Die PR-Abteilung kümmert sich um die Öffentlichkeitsarbeit. Regularien und Gesetze erfordern die Bekanntmachung von Datendiebstählen. Als Beispiel: Die DSGVO erlaubt 72 Stunden vom Entdecken eines Vorfalles bis zum Veröffentlichen des Problems. Es bleibt den Kommunikationsprofis überlassen, den richtigen Wortlaut und die korrekte Tiefe der veröffentlichten Daten zu bestimmen. Ein positives Beispiel aus jüngster Zeit ist der Umgang von Cloudflare mit einem Firewall Problem im Juli; die angewandte Transparenz hat den Großteil des durch den Vorfall verlorenen Vertrauens wiederhergestellt.

Die IT Abteilung hat jetzt andere Sorgen, nach dem Abschalten ist es je nach Tragweite des Vorfalls unerlässlich, zuerst Beweise zu sichern. Der aktuelle Zustand wird dabei auf ein dediziertes Backup System gespielt, und VMs bekommen spezielle Snapshots. Logs werden kopiert und gezielt aufbereitet, und es kann gemeinsam mit den Verantwortlichen mit der Dokumentation des Vorfalls begonnen werden. Der Report muss eine klare Bestandsaufnahme enthalten sowie eine detaillierte Bewertung der ergriffenen Aktivitäten, was gut und was weniger gut gelaufen ist und welche Kosten entstanden sind, um künftig einen gleichartig gelagerten Incident zuverlässig auszuschließen.

Vom Angreifer gelöschte Daten werden vom Backup wiederhergestellt. In nicht wenigen Fällen wurde die Konfiguration von Geräten geändert, auch diese gilt es wieder zurück zu setzen. Eine IT-Inventarliste kann zu Rate gezogen werden, um sicherzustellen, dass alle Elemente in der Umgebung wie beispielsweise Access Points, Server, aber auch Anwendungen, wieder beziehungsweise noch da sind. Aber auch nur dies, „Schläferzellen“ können auch in der IT existieren.

Kontinuität, aber nicht „Business as usual“

Was auch immer passiert ist, darf nie wieder passieren. Also müssen die ausgenutzten Schwachstellen beseitigt werden. Sämtliche Systeme, die versagt haben, sollten in Frage gestellt werden. Das bedeutet nicht automatisch, dass zum Beispiel die Firewall oder der Malware-Filter als unzureichend eingestuft und ausgetauscht werden müssen, aber in jedem Falle steht eine Diskussion mit dem Hersteller an.

Nicht mehr unterstützte Software oder veraltete Versionen, die noch in Betrieb sind, können ernsthafte Probleme darstellen. Gerade im öffentlichen Sektor und im Gesundheitswesen wird aus den verschiedensten Gründen noch auf „legacy“ Produkte zugegriffen, die nicht einfach ausgetauscht werden können. Sehen wir es einmal positiv; der Wille ein Budget zur Investition in ein neues System bereitzustellen, dürfte zu diesem Zeitpunkt gestiegen sein. Aktuell unterstützte Systeme sind selbstverständlich automatisiert zu patchen.

Traurig ist es jedoch, wenn die Ursachenfindung festgestellt hat, dass das Problem hausgemacht war und vermeidbar gewesen wäre. Ein leider oft anzutreffendes Beispiel ist unzureichendes Berechtigungsmanagement. Bei einer prominenten Spielekonsole beziehungsweise dem darunterliegenden Netzwerk des Anbieters kam es zu einem Sicherheitsvorfall, weil das Konto eines Lieferanten auch Jahre nach der letzten Benutzung nicht gelöscht worden ist. Auch Handlungsprotokolle und Incident-Management Pläne sollten an dieser Stelle noch einmal überprüft werden. Hätte man schneller reagieren können, wurden vielleicht nicht die richtigen Personen involviert?

Letztendlich sollte man nicht scheuen und eventuelle externe Hilfe wie etwa von einem Managed Security Service Provider (MSSP) in Betracht ziehen. Gerade in KMU sieht man sich Problemen mit der Priorisierung und Interessenskonflikten gegenüber. Wenn ein MSSP nicht in die Budgetplanung passt, empfiehlt sich das Umschauen auf dem Markt nach einer erschwinglichen Security Software, die auch von IT-Profis aus anderen Fachbereichen als der Security bedient werden kann.

Über den Autor: Sascha Giese ist Head Geek bei SolarWinds.

(ID:46270152)