Ein Incident Response-Plan sorgt dafür, dass im Falle eines Sicherheitsvorfalls die richtigen Mitarbeiter und Verfahren festgelegt sind, um eine Bedrohung effektiv zu bekämpfen. Ein Incident Response Plan stellt sicher, dass eine strukturierte Untersuchung stattfinden kann, um eine gezielte Reaktion zur Eindämmung und Behebung der Bedrohung zu ermöglichen. Es ist Freitagnachmittag und nach einer ruhigen Woche, in der Sie für das IT-Supportportal Ihres Unternehmens gearbeitet haben, sind Ihre Gedanken bei der Flasche Wein, die Sie kaltgestellt haben, um sich einen entspannten Abend mit Netflix zu gönnen. Der Gedanke wird unterbrochen, als Ihr Schreibtischtelefon klingelt. Vermutlich wieder ein Mitarbeiter, der sein Passwort zurücksetzen möchte. Die Panik in der Stimme des Anrufers wird jedoch schnell deutlich. Er kann keine seiner Dateien öffnen und fragt, ob Sie wissen, was eine Bitcoin-Zahlung ist? Wahrscheinlich kein großes Problem, etwas Malware auf einem einzelnen Laptop ist noch keine Katastrophe. Als Sie sich jedoch umdrehen und mehrere Telefone im Büro klingeln sehen, merken Sie, dass es wohl doch mehr zu sein scheint als ein einziger mit Malware infizierter Laptop. Zu allem Überfluss lehnt sich ein Kollege zu Ihnen herüber, um Ihnen mitzuteilen, dass ein Server mit Kundendaten ebenfalls mit Ransomware infiziert wurde. Dieses Szenario hat sich schon viele Male auf der ganzen Welt abgespielt. Wie effektiv Sie auf diese Situation reagieren, hängt von der Antwort auf eine Frage ab: „Haben Sie einen Incident Response-Plan?“
Der Incident Response-Plan besteht aus Schlüsselkriterien, die mit zunehmender Reife der Sicherheitsstrategie eines Unternehmens weiterentwickelt werden können. Bei der Erstellung eines Vorfallreaktionsplans sind mehrere Überlegungen wichtig. Die Unterstützung durch die Unternehmensleitung ist von größter Bedeutung. Die Erstellung eines Incident Response-Plan sollte vor allem nicht undurchdacht nach Schema F erfolgen. Wenn er nicht von der Unternehmensleitung unterstützt wird, besteht die Gefahr, dass er bis zu seiner Verwendung in den Akten liegt. Die Unternehmensleitung sollte darlegen, was aus einem Verfahrens- und Personalstandpunkt erforderlich ist, und dafür sorgen, dass jede erforderliche Unterstützung geleistet wird. Definieren der wichtigsten Interessenvertreter. Kontaktdetails für Schlüsselpersonen und -teams innerhalb und außerhalb der Geschäftszeiten müssen dokumentiert werden. Klar kommunizieren. Es sollte festgelegt werden, wer die Verantwortung für das Versenden von Mitteilungen, die Zuweisung von Aufgaben und für geeignete Maßnahmen trägt. Überlegen Sie auch, wer in die Kommunikation über Ereignisse einbezogen werden muss und wie viele Details je nach Empfänger erforderlich sind. Aufgaben, die Sicherheitsteams zugewiesen sind, müssen präzise und technisch sein, während die Mitteilungen an die Unternehmensleitung klar und frei von technischem Jargon sein müssen. Definieren Sie, was ein Ereignis ausmacht. Legen Sie fest, welche Ereignisse als „Normalbetrieb“ behandelt werden können und ab wann die Sicherheitsnotlage ausgerufen werden sollte und das ganze Team benötigt wird.
SANS hat vor einigen Jahren das Incident Handler’s Handbook veröffentlicht, das nach wie vor der Standard für Incident Response-Pläne ist. Es sieht eine sechsstufige Struktur vor, mit der Sie Ihren individuellen Unternehmensplan erstellen können.
Die Vorbereitung auf ein mögliches Sicherheitsereignis ist der Schlüssel zu einer erfolgreichen Reaktion. Ich empfehle mit Nachdruck, einige Ablaufpläne zu entwickeln, die bei der Triage von Ereignissen eine Orientierungshilfe für das SOC bieten. Darin werden klare Anweisungen darüber vermittelt, wie ein Ereignis zu priorisieren und wann es zu eskalieren ist. Diese sollten allgemein gehalten sein und sich auf bestimmte Bereiche wie DDoS, Malware, Insider-Bedrohungen, unbefugten Zugriff und Phishing konzentrieren. Die Ablaufpläne und Verfahren sollten an den Personen und Teams getestet werden, die sie ggf. verwenden werden. Planübungen sind eine ausgezeichnete Möglichkeit, das Wissen zu festigen und zu sehen, ob Verbesserungen möglich sind.
Sie können eine Sicherheitsbedrohung nur dann erfolgreich beheben, wenn Sie die Größe und den Umfang eines Ereignisses kennen. Beginnen Sie mit „Patient Zero“, dem Gerät, das als erstes kompromittiert wurde. Ziel ist es, die Grundursache der Kompromittierung zu verstehen, sich aber nicht nur auf das eine Gerät zu konzentrieren. Könnte sich die Bedrohung beispielsweise ausgebreitet und lateral bewegt haben? Eine echte Identifizierung eines Ereignisses ergibt sich aus der Sammlung von Komprimittierungsindikatoren (Indicators of Compromise, IOCs). Anstatt nur das ursprünglich infizierte Gerät zu ermitteln, sollten Sie versuchen, eindeutige IOCs zu identifizieren, die verwendet werden können, um in Ihrem gesamten Netzwerk nach weiteren Anzeichen der Kompromittierung zu suchen. Wenn sich der Vorfall auf eine Malware-Infektion bezieht, dann stellen Sie die folgenden Fragen: Welche Netzwerkverbindungen stellt die Malware her? Verbindet sich die Malware mit bestimmten Domains? Welche Dateien werden auf der Festplatte erstellt? Welche laufenden Prozesse werden erstellt? Gibt es eindeutige Registrierungsschlüssel, die erstellt wurden? Diese Daten können dann verwendet werden, um nach weiteren Anzeichen der Kompromittierung zu suchen und andere infizierte Computer in Ihrem Netzwerk zu identifizieren.
Sobald der Umfang eines Ereignisses erfolgreich identifiziert wurde, kann man mit der Eindämmung beginnen. Hier werden die kompromittierten Geräte innerhalb des Netzwerks vom übrigen Netzwerk isoliert, um die Ausbreitung eines Angriffs zu verhindern. Kurzfristige Eindämmung kann verwendet werden, um ein Gerät zu isolieren, das viel Angriffs-Traffic zeigt. Eine langfristige Eindämmung kann notwendig sein, wenn eine Tiefenanalyse erforderlich ist, die zeitaufwändig sein kann. Dazu muss man ggf. ein Image des Geräts erstellen und Festplatten-Forensik durchführen. Daraus lassen sich weitere IOCs erschließen, und die Identifizierungsphase muss möglicherweise erneut durchlaufen werden.
Sobald das Ereignis erfolgreich behoben wurde, kann man anfangen, die Bedrohung zu beseitigen. Wie genau das abläuft, hängt davon ab, wodurch ein Gerät kompromittiert wurde. Das Patching von Geräten, die Entschärfung von Malware, die Deaktivierung kompromittierter Konten sind alles Beispiele dafür, was in der Beseitigungsphase eines Vorfalls erforderlich sein kann.
Das Ziel der Wiederherstellungsphase nach einem Ereignis ist die Wiederaufnahme des normalen Betriebs. Wenn saubere Backups verfügbar sind, können diese zur Wiederherstellung des Betriebs verwendet werden. Alternativ muss jedes kompromittierte Gerät einzeln wiederhergestellt werden, um eine saubere Wiederherstellung zu gewährleisten. Möglicherweise muss eine zusätzliche Überwachung der betroffenen Geräte implementiert werden.
Sobald die Bedrohung vollständig beseitigt wurde, muss man eine Antwort auf die Frage finden: „Wie können wir verhindern, dass sich so etwas wiederholt?“ Eine Sitzung, die als Post Incident Review (PIR, z. Dt. Ereignisnachbesprechung) bezeichnet wird, sollte stattfinden und Vertreter aller an dem Vorfall beteiligten Teams einbeziehen. Im Rahmen dieser Plattform lässt sich diskutieren, was während des Vorfalls gut gelaufen ist und was verbessert werden könnte. Hier wird der Ereignisreaktionsplan auf der Grundlage der Ergebnisse des PIR verfeinert, und die Verfahren und Ablaufpläne werden geändert, um alle vereinbarten Änderungen zu berücksichtigen.
Ablaufpläne erstellen. Ablaufpläne dienen als Anleitung für das SOC bei der Triage verschiedener Ereignisse und dem Sammeln der relevanten Beweise. Konzentrieren Sie sich auf die wichtigsten Angriffsszenarien, mit denen Unternehmen konfrontiert sind – Malware, DDoS, unbefugter Zugriff, Phishing und Insider-Bedrohungen. Diese Dokumente sollten darlegen, was eine Eskalation für das Incident Response-Plan-Team auslösen sollte, und Ratschläge dazu geben, welche Beweise gesammelt werden müssen. Sie sollten auf hoher Ebene konzipiert und nicht allzu detailliert sein, um nicht zu komplex zu werden. Führen Sie Übungen zu Cyber-Bedrohungen durch. Bereiten Sie sich auf den Ernstfall vor, indem Sie mehrere Angriffsszenarien durchspielen. Das lässt sich auch relativ einfach gestalten, indem man etwa einige Planübungen am Schreibtisch durchführt. Die Erstellung mehrerer Angriffsszenarien, die von den entsprechenden Teams besprochen werden können, ist eine gute Möglichkeit, um alle vorhandenen Ablaufpläne zu testen; es trägt auch dazu bei, etwaige Lücken in einem Incident Response-Plan zu ermitteln, und sollte mindestens einmal im Jahr überprüft werden. Beginnen Sie mit der Bedrohungsjagd. Es ist eine Sache, auf einer brandneuen Plattform auf einen Alarm zu warten. Ein Incident Response-Team entwickelt sich jedoch erst bei der aktiven Suche nach verdächtigen Aktivitäten weiter. So werden nicht nur potenzielle Kompromittierungen oftmals früher entdeckt, sondern die Personen, die diese Ad-hoc-Untersuchungen durchführen, können sich auch eine investigative Denkweise aneignen. Diese Fähigkeiten und diese Art von Denkweise sind genau das, was während der Identifikationsphase eines Ereignisses gebraucht wird: Abfragen des Netzwerk-Traffics, Beobachten ungewöhnlicher Port-Nutzungen und Untersuchen ungewöhnlicher Prozesse, um das Ausmaß eines Ereignisses zu verstehen. Wenn das SOC ein ausgeprägtes Verständnis davon hat, wie die „Normalität“ aussieht, wird es viel einfacher, bösartige Aktivitäten zu erkennen.
EinenIncident Response-Plan zu erstellen wirkt oftmals wie eine überwältigende Aufgabe. Eine Vorlage kann hier Struktur und Anleitung bieten, um den Prozess zum Erfolg zu führen. NCSC-Planungsleitfaden – Das NCSC (National Cyber Security Centre) ist eine britische Regierungsorganisation, die kritische britische Unternehmen im Bereich der Cybersicherheit unterstützt. Als wichtige Autorität auf dem Gebiet der Cybersicherheit sind ihre Empfehlungen bei der Planung eines Incident Response-Plans sehr wertvoll. Sysnets Incident Response-Plan Vorlage – Beschreibt die Erkennung eines Sicherheitsereignisses, die Rollen und Verantwortlichkeiten der Hauptbeteiligten, die Schritte im Incident Response-Plan und was bei verschiedenen Arten von Ereignissen zu beachten ist. Incidentresponse.com bietet mehrere Vorlagen für Ablaufpläne, die Szenarien wie Malware, Phishing und unbefugten Zugriff abdecken und alle dem NIST Incident Response Framework zugeordnet sind. Dabei handelt es sich um separate, eigenständige Dokumente, auf die jedoch im Incident Response-Plan Bezug genommen werden sollte. Um zu verstehen, wann ein Ereignisreaktionsplan verwendet wird, bieten wir im Varonis-Webinar zu Incident Responses eine Live-Angriffssimulation. Während dieser Simulation bieten unsere Sicherheitsanalytiker eine kurze Tour von Varonis für Office 365, führen den Angriff vom Eindringen über die Berechtigungseskalation bis hin zur Exfiltration durch und zeigen Ihnen dann, wie Sie DatAlert zur Erkennung und Reaktion einsetzen können.
Der Staub legt sich, die Bösewichte sind besiegt und das CSIRT-Team hat den Incident Response bis ins feinste Detail umgesetzt.Wie geht es weiter? Machen Sie eine Bestandsaufnahme und füllen Sie das Arsenal für die nächste Schlacht auf. Optimieren Sie Ihre Incident Response oder versuchen Sie, die bereits vorhandene Überwachung zu verbessern. Gibt es zusätzliche Protokolle, die während eines Ereignisses nicht verfügbar waren und die aktiviert werden müssen? Gibt es eine Kompetenzlücke im Sicherheitsteam? Muss die Patching-Richtlinie des Unternehmens überprüft werden? Indem der Incident Response-Plan durchgehend überprüft und optimiert wird, lässt sich dafür sorgen, dass nicht nur die Reaktion auf einen Vorfall verbessert wird, sondern dass auch die Angriffsfläche verringert wird. Wenn zusätzliche Kontrollen und Verbesserungen der Sicherheitslage eines Unternehmens vorgenommen werden, wird dies letztlich zu weniger Sicherheitsereignissen führen. Nach dem Lesen dieses Artikels sollten Sie das Wissen und die Ressourcen haben, um einen Incident Response-Plan erfolgreich zu entwickeln und implementieren. Um sicherzustellen, dass Ihre Daten geschützt sind, registrieren Sie sich für eine Testversion der Varonis Data Security Platform. Wir bieten branchenführende Verhaltensanalysefunktionen für all Ihre kritischen Datenspeicher und Infrastrukturen.