Incident Response - Teil 2

Die beste Zeit zur Vorbereitung auf Security-Incidents ist, vor dem Incident. Eine gute Vorbereitung verhindert Fehler im Notfallmodus und schafft Klarheit zu Verantwortlichkeiten, Aufgaben und das Ziel des Krisenteams. In diesem Teil meiner Blog-Serie erkläre ich, was man im Vorfeld eines Hackerangriffs am besten planen kann.

Wie man richtig auf einen Hackerangriff reagiert, lest ihr in Teil 3 meiner Blog-Serie

Das Management sagt "Ja!"

Wir berücksichtigen die Vorbereitungsmaßnahmen auf einen Sicherheitsvorfall schriftlich in unseren Zielvereinbarungen. Steht das Management nicht hinter den Maßnahmen, ist das Budget womöglich zu zu gering bemessen und das "Dringende" sticht im täglichen Betrieb stets das "Wichtige"; Vorbereitungsmaßnahmen laufen ins Leeren. Auch in der Reaktion auf einen bereits erfolgten Angriff wird die Mannschaft weiter im operativen Sumpf dümpeln, wenn das Management falsche Prioritäten setzt.

Zusammenstellung des Krisen-Teams

Im Zuge der Vorbereitung stellen wir ein Krisen-Team für den Ernstfall auf. Die Teams können interdisziplinär sein und sind nicht an bestehende organisatorische und hierarchische Rahmenbedingungen gebunden. Wir definieren Teamleiter, z. B. für die folgenden Teams:

• Hunting: Erhebung der Aktivitäten und Ausbreitung des Angreifers
• Recovery: Planung des Takeback und der Wiederherstellung der Infrastruktur
• Legal: Einhaltung rechtlicher Rahmenbedingungen
• Public Relations: Vorbereitung und Veröffentlichung von Pressemeldungen; Beobachtung der Presse
• Purchasing: Einkauf im Krisenfall

Teamleiter agieren weitgehend autonom und wählen ihre Mitarbeiter selbst aus. Sämtliche für den Krisenfall vorgesehene Kräfte unterzeichnen - am besten im Vorhinein - Geheimhaltungsvereinbarungen. Vorbereitungsmaßnahmen auf einen möglichen Sicherheitsvorfall sind in den (quartalsmäßigen/jährlichen) Zielvereinbarungen der Teamleiter berücksichtigt.

Identifikation und Abschottung unternehmenskritischer Systeme

In unserem Szenario (siehe Teil 1) werden unternehmenskritische Systeme während des Vorfalls unter Hochdruck identifiziert und abgeschottet. Dies erledigen wir bereits im Zuge der Vorbereitung auf einen Sicherheitsvorfall.

Eine "Business Impact Analyse" (BIA) evaluiert die Wichtigkeit einzelner Systeme für den Geschäftsbetrieb. Wir identifizieren also Systeme die für folgende und ähnliche Prozesse essentiell sind:

• (Dienst-)Leistungserbringung
• Produktionsstraßen
• Geschäftsgeheimnisse
• und andere.

Wir betrachten auch Abhängigkeiten dieser Systeme, wie z. B.:

• Zentrales Benutzermanagement
• Netzwerkkomponenten
• Internet- und Standort-Verbindungen

Priorisieren ist angesagt. Ist z. B. ein Abrechnungssystem im Krisenfall nicht essentiell und können Rechnungen auch ein paar Wochen verspätet versandt werden, ist das Abrechnungssystem auch kein unternehmenskritisches System. Wenn mehr als 10-20% aller Systeme als unternehmenskritisch identifziert wurden, sollte man die Priorisierung noch einmal überarbeiten.

Wir schränken die Erreichbarkeit unternehmenskritischer Systeme so weit wie möglich ein. Dies erreichen wir nicht nur durch eine klassische Netzwerksegmentierung (z. B. über ein Zonenkonzept), sondern auch durch Einschränkungen innerhalb der einzelnen Zonen und Segmente. Benutzerberechtigungen werden restriktiv vergeben und unterliegen regelmäßigen (z. B. halbjährlichen) Überprüfungen.

Wir statten (zumindest) unternehmenskritische Systeme mit "Advanced Threat Protection" (ATP) Software aus. Diese wertet nicht nur klassische Log-Einträge aus, sondern analysiert auch Systemcalls, und Aktivitäten im Arbeitsspeicher. Damit erkennen wir Angriffe auf wichtige IT-Infrastruktur frühzeitig.

Equipment und Kommunikation

Im Falle eines Security Incidents können wir unseren Client-PCs nicht weiter trauen. Ebenso unseren Fileshares und Kommunikationstools.

Gute Vorbereitung

Wir evaluieren externe Kommunikations- und Filesharing-Dienste, die nicht in unsere IT-Umgebung eingebunden sind (z. B. über Single Sign-On). Im besten Fall lizenzieren wir die Dienste bereits im Vorfeld und testen sie regelmäßig.

Ein Pool an Notebooks für den Krisenfall steht bereit. Die Geräte können - müssen aber nicht - in die internen Netzwerke eingebunden werden. Eine Anbindung der Geräte oder der Benutzer in das Active Directory erfolgt nicht.

Bessere Vorbereitung

Sämtliche Kommunikationstools des Unternehmens arbeiten mit Ende-zu-Ende-Verschlüsselung. Wir verschlüsseln Daten auf Fileshares standardmäßig clientseitig. Damit hat ein Angreifer im besten Fall keinen Zugriff auf Daten kompromittierter Systeme.

Verpflichtende Meldungen

Wir evaluieren, ob, wie und an wen ein Sicherheitsvorfall gemeldet werden muss. Dokumentiert werden zumindest:

• Meldestelle (z. B. Datenschutzbehörden, NIS-Meldestellen, Regulatoren - etwa für Telekommunikation, Vertragspartner, CERTs, BSI, etc.)
• Art des Vorfalls (z. B. Betriebsunterbrechung, Diebstahl personenbezogener Daten, etc.)
• Fristen
• Meldeweg (z. B. Web-Formular, Postweg, etc.)

Einkauf im Krisenfall

Wir erarbeiten einen Einkaufsprozess für den Krisenfall. Dieser umfasst beispielsweise:

• Abweichungen zum Standard-Einkaufsprozess
• Vier-Augen-Prinzip
• Abstimmung im Krisenstab
• Alternative Zahlungsmittel (z. B. Notfall-Kreditkarten, etc.)
• (Nachträgliche) Freigaben
• Behandlung von Interessenskonflikten

Pressemeldungen

Der erste Berichterstatter kontrolliert eine Nachricht am nachhaltigsten. Darum kann es sinnvoll sein, die Öffentlichkeit proaktiv über einen Vorfall zu informieren. Wir verfassen bereits im Vorfeld zwei bis drei Pressemeldungen für unterschiedliche Risikoszenarien. Dies schafft bei der Pressestelle Verständnis für das Thema IT-Security und Sicherheitsvorfälle. Wir können außerdem im Krisenfall auf vorgefasste Textbausteine zurückgreifen.

Wir berichten wahrheitsgetreu und möglichst konkret. Falsche Informationen werden entlarvt werden und schaffen großes Misstrauen. Schwammige Informationen regen zu Spekulationen an und überlassen Dritten die Kontrolle über die Meldung (z. B. Journalisten, Sicherheitsforschern).

Eine Pressemeldung beinhaltet - sofern bekannt, verfügbar und für die Öffentlichkeit bestimmt - folgende Inhalte:

• Was ist passiert?
• Seit wann ist der Angriff im Gange?
• Wann wurde der Angriff entdeckt?
• Welche Daten sind betroffen?
• Wie werden Betroffene informiert?
• Was war der Eintrittsvektor?
• Welche Maßnahmen wurden und werden aktuell gesetzt oder sind geplant?
• (Wer ist der Angreifer?)*

*Eine eindeutige Identifikation des Angreifers ist meist nicht möglich und spekulativ. Manchmal kann die Herkunft der Angreifer grob eingeordnet werden. Dies kann etwa durch IP-Adressen (meist unzuverlässig, da verschleiert), Benutzte Schadsoftware oder die zeitliche Aktivität des Angreifers (Rückschlüsse auf die Zeitzone) erhoben werden.

Spielt!

Alles was beherrscht werden will braucht Übung. So auch der Krisenfall.

Regelmäßige Planspiele schaffen Vertrautheit mit bisher unbekannten Situationen und schweißen das Team zusammen. Der Krisenfall könnte etwa einmal pro Jahr im kleinen Rahmen (Krisenstab) und einmal pro Jahr im größeren Rahmen mit kleineren Subteams geübt werden. Wenn ihr keine Erfahrung in der Durchführung von Planspielen habt, zahlt es sich aus, sich Unterstützung zu holen.

Wie man richtig auf einen Hackerangriff reagiert, lest ihr in Teil 3 meiner Blog-Serie.
Welche Fehler durch mangelnde Vorbereitung auf einen Sicherheitsvorfall passieren können, erfahrt in in Teil 1 meiner Serie.

Die in diesem Artikel vorgeschlagenen Maßnahmen sind nicht vollzählig, stellen aber einen Leitfaden für eine Vorbereitung auf einen Security Incident dar. Aus den Vorbereitungsarbeiten werden sich viele weitere Maßnahmen ergeben. Manche Tätigkeiten können in Ruhe, durchdacht und ohne Druck bereits im Vorfeld durchgeführt werden.

Gerne höre ich euer Feedback und eure Inputs auf meine Vorschläge. Ich werde den Artikel auch regelmäßig durch neue Vorschläge und Erfahrungen ergänzen. Bitte schreibt an support@offensity.com!