Incident Response - Teil 3

Die Kommunikation während eines Sicherheitsvorfalls stellt Unternehmen vor eine große Herausforderung. Die Umstände ändern sich - besonders in der Anfangsphase - in sehr kurzen Zeiträumen und oft ist unklar, womit andere Teams beschäftigt sind.

Für ein klares Zielbild über die Subteams hinweg empfehle ich - wie auch im täglichen Betrieb - die Anwendung von Objectives and Key Results (OKRs).

Über die Vorbereitung auf den Krisenfall lest ihr in Teil 2 dieser Blog-Serie.

Im Krisenmodus besteht häufig die Gefahr, dass technische und organisatorische Teams parallel arbeiten und wenig Einblick in das Vorgehen der jeweils anderen Teams haben. So passiert es häufig, dass etwa gleichzeitig unterschiedliche Tools zum selben Zweck durch die Teams angeschafft werden. Um das zu verhindern braucht man eine gute Kommunikation und eine gemeinsame Zielsetzung.

Anmerkung: Der womöglich schwerste Schritt die Erkennung und das Eingestehen eines Security-Incidents. Im Sinne der Schritte "Prevent - Identify - Respond" konzentriere ich mich in diesem Teil jedoch ausschließlich auf den letzten Schritt.

Das Krisenteam

In vielen Organisationen spielt die Geheimhaltung eines Vorfalls eine wichtige Rolle. Darum muss der Krisenstab (die Leiter der einzelnen Krisen-Teams) entscheiden, wer in den Vorfall involviert wird oder nicht. Das geschieht im Idealfall bereits im Zuge einer Vorbereitung auf Sicherheitsvorfälle (siehe Teil 2). Manche Mitarbeiter können mit sehr genau definierten und konkreten Aktivitäten beauftragt werden, ohne über den Vorfall informiert zu werden. Man muss sich jedoch bewusst sein, dass solche Aufträge nicht die Art sind, wie man heute führen sollte und das Ergebnis ein anderes sein könnte, als man sich erwartet. Ein Beispiel:

Ein Mitarbeiter wird damit beauftragt, Netzwerkpfade zu erheben, über welche man ein bestimmtes, unternehmenskritisches System erreicht. Da er über den aktuellen Vorfall nicht informiert ist, fokussiert er sich auf die Zugänge von Fremdfirmen ins interne Netzwerk. Diese Information hilft uns jedoch nicht, da wir - im Gegensatz zu unserem Mitarbeiter - wissen, dass sich der Angreifer bereits im internen Netzwerk befindet.

Hat ein Mitarbeiter eine Geheimhaltungsvereinbarung unterzeichnet und soll im Krisenteam mitarbeiten, sollte er auch vollumfänglich über sämtliche Sachverhalte informiert werden. Die Einhaltung des Need-To-Know-Prinzips innerhalb des Krisenteams führt zu schlechter Kommunikation, unklaren Zielvorgaben und damit zu einer ineffizienten Arbeitsweise.

Der Krisenstab bestimmt Objectives

Der Krisenstab entscheidet über die Objectives (also die übergeordneten Ziele). Sollte das Know-How des Krisenstabs zu einseitig sein (etwa zu viele Techniker ohne Management-Erfahrung oder umgekehrt), ist es besonders empfehlenswert, zusätzliche Know-How-Träger einzuladen.

Die Objectives sollten untereinander priorisiert werden, um Einzelmaßnahmen gegeneinander abwägen zu können. Objectives könnten z. B. sein:

1. Lateral Movement in kritische Netzwerksegmente verhindern, um unternehmenskritische Systeme zu schützen
2. Angreifer aus der Organisation drängen
3. Rechtliche Bestimmungen (etwa Meldepflichten) einhalten
4. Prävention unkontrollierter Veröffentlichung des Incidents

Mitarbeiter könnten aus dieser Priorisierung z. B. ableiten:

Ein Firewall-Administrator darf in den Vorfall eingeweiht werden, da dieser das Risiko von lateral Movement reduzieren kann (Objective 1). Dabei erhöht sich das Risiko einer unkontrollierten Veröffentlichung (Objective 4; je mehr involvierte Personen, desto höher das Risiko eines Leaks). Die Priorisierung der Objectives ermöglicht hier die Entscheidung zugunsten von Objective 1.

Objectives sind dabei nicht in Stein gemeißelt. Die Umstände werden sich laufend ändern und somit auch die Objectives.

Key Results sind Teamsache

Jeder Mitarbeiter ist Spezialist ein seinem individuellen Fachgebiet. Der Krisenstab ist bei weitem nicht der beste oder der alleinige Know-How-Träger. Der Krisenstab informiert das gesamte Krisenteam über die festgelegten Objectives. Jeder Mitarbeiter ist aufgerufen, Maßnahmen vorzuschlagen, die auf die Objectives einzahlen. Vorgeschlagene Maßnahmen werden den Objectives und einem Verantwortlichen zugeordnet. Jedes Mitglied des Krisenteams kann für ein Key Result verantwortlich sein. Der Verantwortliche ist für die operative Umsetzung des Key Results zuständig.

Key Results dürfen diskutiert werden; sie müssen jedoch nicht auf einem Konsens basieren. Ein Beispiel für mögliche Key Results für unser Objective 1 ist:

Objective: Lateral Movement in kritische Netzwerksegmente verhindern, um unternehmenskritische Systeme zu schützen

• KR #1: Mögliche Maßnahmen für host-based (a) und network-based (b) Monitoring kritischer Netzwerksegmente werden evaluiert
• KR #2: Erarbeitung eines Prozesses: Welche Maßnahmen sind notwendig, wenn ein infizierter Server in einem kritischen Netzwerksegment identifiziert wurde
• KR #3: Die ausgewählte host-based Monitoring-Software wird auf mehr als >60% der Server in kritischen Netzwerksegmenten ausgerollt
• KR #4: Die ausgewählte network-based Monitoring-Software wird auf sämtlichen internen Firewalls, die in kritische Netzwerksegmente führen, aktiviert

Stand up!

Zwei Mal täglich sollte das gesamte Krisenteam - virtuell oder physikalisch - zusammenkommen. Key Result-Verantwortliche legen - sofern es Berichtenswertes gibt - den Arbeitsfortschritt dar. Key Results können - wenn sie hinfällig sind - ersatzlos gestrichten werden. Die täglichen Stand-Ups können auch genutzt werden, neue Key Results zu definieren.

Es empfehlen sich z. B. Uhrzeiten wie 10.00 und 14.00 Uhr, um genügend Vor- und Nachbereitungszeit zu haben.

Unseren Leitfaden für die Vorbereitung auf den Ernstfall findet ihr in Teil 2 dieser Blog-Serie.
Weitere Informationen über OKRs findet ihr in unserem Blog-Post: Wie OKRs Ihre IT-Sicherheit verbessern.

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!