Detection and Response
Gegen die Zeit: Cyber Incident Response
Ein einsatzbereiter Incident Response-Prozess ist von entscheidender Bedeutung, wenn ein Angriff entdeckt wird. Unser fiktiver Erfahrungsbericht eines Director of Incident Response führt dies eindrucksvoll und überzeugend vor Augen.
Experten sind sich im Prinzip einig, dass Cybersicherheitsverletzungen unvermeidlich sind. Die einzigen Variablen sind der Zeitpunkt und die Schwere der Angriffe - und wie gut ein Unternehmen darauf vorbereitet ist. Fortschrittliche Verteidigungsmaßnahmen sind unerlässlich, aber zu einer soliden Sicherheitsstrategie gehört auch ein gut definierter Incident Response-Prozess.
Dieser Prozess variiert je nach den individuellen Gegebenheiten des Unternehmens, sollte aber die Schritte zur Erkennung, Eindämmung und Wiederherstellung nach einem erfolgreichen Angriff umfassen, ebenso wie alle Verantwortlichkeiten und Kommunikationskanäle, die Einschaltung eines Rechtsbeistands und die Verfahren nach der Lösung des Problems.
Wie ein solcher Plan in der Praxis hilft, führen über das folgende fiktive Szenario anschaulich vor. Der festgelegte Ablauf greift auf Trend Micros Erfahrung in der Unterstützung von Unternehmen bei der Definition, Implementierung und Verwaltung von Incident Response Plänen zurück. Die Situation: Das Team des Security Operations Center (SOC) eines weltweit tätigen Metallherstellers stellt eine Netzwerkanomalie fest und ruft den Director of Incident Response Stacy Bell an...
Incident Response-Prozess: Der Alert
Am Freitagabend klingelte kurz vor 20.30 Uhr mein Telefon. Mein SOC-Manager Raj sagte, das Team habe einen Alarm von einem AV-Produkt auf einem Dateiserver im Rechenzentrum in Cincinnati erhalten. Auf den ersten Blick sah es nach nichts Besonderem aus, aber nach einer kurzen Prüfung stellte sich heraus, dass jemand eine Fernverwaltungssoftware (RM) installiert hatte, ein Programm, das wir zwar schon mal verwendet hatten, aber nicht häufig und auch nicht in letzter Zeit.
Raj und ich waren uns einig, kein Risiko eingehen zu wollen. Vor zwei Tagen hatten wir von unserem Cybersecurity-Anbieter eine Meldung über eine Ransomware-Bedrohung erhalten, die auf Fertigungsunternehmen wie unseres abzielte. Die Angreifer waren dafür bekannt, dass sie sich tage- oder wochenlang in einem Netzwerk aufhielten und mit Hilfe von RM-Tools Daten abschöpften und Malware verbreiteten, bevor sie dann zuschlugen.
Ich fuhr sofort ins Büro, 20 Minuten von meinem Wohnort entfernt. Raj und das Team hatten bereits damit begonnen, unser Incident Response Playbook durchzugehen: Der informelle erste Schritt bestand darin, eine Kanne Kaffee aufzusetzen, wissend, dass es eine lange Nacht werden könnte.
Ich ging die Incident Response-Schritte schnell durch, obwohl ich sie auswendig kenne. Ich war froh, dass unsere XDR-Plattform in Betrieb war. Mein CISO und ich hatten letztes Jahr dem Vorstand den Nutzen von XDR dargelegt und waren auf Verständnis gestoßen für das Mehr an Sichtbarkeit, Kontrolle und Geschwindigkeit in Situationen wie heute der von heute Abend. Denn wenn es einen Angriff im Netzwerk gibt, ist eines ganz klar: Zeit ist immer entscheidend!
Die Ausbreitung einschätzen
Das Team führte mithilfe unserer XDR-Plattform eine Callback-Server (C2)-Analyse durch. Es bestätigte sich, dass eine nicht autorisierte IP-Adresse eine Fernverbindung zum Dateiserver hergestellt hatte. Mir wurde flau im Magen, als sie sagten, dass Daten exfiltriert wurden, auch wenn es sich angeblich nicht um sensible oder private Daten handelte. Ich wies meine Mitarbeiter an, unserem Juristen-Team eine vollständige Übersicht zu geben - sie sind diejenigen, die unsere Haftbarkeit feststellen.
Wir isolierten den Server und nahmen ihn vom Netz.
Der nächste Schritt in unserem Cyber Incident Response-Prozess bestand darin, herauszufinden, ob und wie weit sich der Angriff ausgebreitet hatte. Das bedeutete zweierlei: Erstens musste das Team herausfinden, ob andere Endpunkte hier oder an unseren weltweiten Standorten betroffen waren, und zweitens musste es den „Patient Zero“ ermitteln, also das Gerät, über das der Angreifer ursprünglich eingedrungen war. Es gab schon Teams, die dachten, mit der Eindämmung des ersten gefundenen Geräts sei das Problem gelöst, nur um dann erneut befallen zu werden, weil andere Rechner infiziert waren.
Wir setzten Netzwerk- und Endpunktsensoren ein, um jedes Gerät im Unternehmen auf Interaktionen mit der nicht autorisierten IP-Adresse zu überprüfen. Wir fanden ein halbes Dutzend Instanzen: zwei in Kanada und vier in Estland.
Ich beauftragte einige Team-Mitglieder, diese Geräte zu isolieren, wohl wissend, dass es damit noch lange nicht getan war. Bedrohungsakteure wechseln häufig während eines Einbruchs die Domäne, so dass diese erste IP-Adresse höchst wahrscheinlich nicht die einzige war, die wir im Auge zu behalten hatten. Wir mussten uns jede weitere eingehende IP-Adresse ansehen und auf weitere Anomalien überprüfen.
Fahndung nach den Verdächtigen
Zu diesem Zeitpunkt stand ich in ständigem Kontakt mit unserem CISO, der unsere Unternehmensleitung auf dem Laufenden hielt. Die SOC-Mitarbeiter standen im Dialog mit Kollegen an unseren anderen Standorten. All dies geschah ohne E-Mail und Textnachrichten. Gemäß dem Incident Response-Plan nutzten wir einen verschlüsselten Messaging-Kanal, um sicherzustellen, dass die internen Gespräche intern blieben, bis wir bessere Erkenntnisse über den Einbruch und seine Auswirkungen gewonnen hatten.
Es war 21:43 Uhr, und eine böswillige Person war immer noch in unserem Netzwerk und startete aktiv einen Cyberangriff. Ich nahm eine „Zero Trust“-Position ein, wissend, dass jeder Endpunkt eine potenzielle Bedrohung darstellte und als verdächtig behandelt werden musste. Wir scannten erneut unser gesamtes Netzwerk sowie alle Geräte und suchten nach Anzeichen für Datenverluste, unzulässige Softwareinstallationen oder andere potenzielle Anzeichen für eine Gefährdung (IOCs).
Diese Untersuchung förderte eine Handvoll weiterer infizierter Geräte zutage, ergab den Malware-Hash, nach dem wir suchen mussten, und brachte uns auf den „Patienten Null“: ein IoT-Steuermodul in der Anlage in Estland, das vor 36 Stunden kompromittiert worden war.
„Alle Türen zuschlagen“
Mithilfe der XDR-Automatisierung gelang es uns sehr schnell, alle identifizierten IOCs auf unsere Netzwerk-Firewalls hochzuladen, um den Perimeter zu schützen. Das verschaffte uns einen Vorteil: Wenn es infizierte Rechner gab, die wir nicht gefunden hatten, konnten wir die Firewalls auf blockierte IOC-bezogene Aktivitäten überwachen, zurückverfolgen und Abhilfe schaffen. Außerdem führten wir für die Netzwerkverbindungen aller betroffenen Geräte ein Reset durch und starteten Sample-Abfragen, um festzustellen, ob „stille“ Rechner - also solche, die sich nicht gemeldet hatten und von unseren Firewalls blockiert wurden - den Malware-Hash enthielten.
Über unseren Incident Response-Prozess identifizierten wir nicht nur die infizierten Geräte, sondern auch die zugehörigen Benutzer und schränkten deren Berechtigungen vorübergehend ein, um jeglichen Missbrauch zu verhindern. Unser Plan legt auch fest, wann und wie wir die Benutzer über diese Einschränkungen informieren mussten; damit waren mehrere Teammitglieder betraut.
Gleichzeitig starteten wir Analysen der Firewall-Logs für Massendatenübertragungen. Wir untersuchten den gesamten Zeitraum von der ersten Infektion bis zum aktuellen Zeitpunkt. Jeder Datendiebstahl schien minimal und unbedeutend zu sein - aber unsere Anwälte würden das letztendlich beurteilen.
Nachdem alle infizierten Geräte erfasst, der Patient Null identifiziert und die Eindämmungsmaßnahmen abgeschlossen waren, bedankte ich mich beim Team und fragte, was ich immer frage, wenn eine Bedrohung erfolgreich eingedämmt wurde: „Habt ihr das gehört? Das war das Zuschlagen der Tür.“
Bereit für das nächste Mal
Wir hatten den Angriff in etwas mehr als zwei Stunden abgewehrt -- kaum genug Zeit, um die Kanne Kaffee zu trinken. Die XDR-Plattform war unbestreitbar eine große Hilfe. Die manuelle Durchführung unseres Incident Response-Prozesses hätte bis zu 12 Stunden gedauert, und wir wären nie so sicher gewesen, dass wir Patient Zero gefunden hatten. Ich vertraue meinem Team voll und ganz, aber es war beruhigend zu wissen, dass nicht jeder ein Superstar sein musste, denn eine gute Technik bot Unterstützung.
Ich war erleichtert, dass es vorbei war, aber auch besorgt. Trotz unserer Verteidigungsmaßnahmen und eines guten Incident Response-Prozesses gelangten die Bösewichte in den Besitz von Daten und setzten Schadprogramme ein. Ja, es hätte schlimmer kommen können. Wir hatten Glück. Aber Glück steht nicht in meiner Stellenbeschreibung.
Ich einigte mich mit dem Team darauf, eine vollständige Zero-Trust-Strategie einzuführen. Das würde nicht einfach sein. Zero-Trust ist ein Monster an Disziplin, aber der Ansatz reduziert die Zahl der Sicherheitsverstöße massiv und hilft, Beinaheunfälle wie den von heute Abend zu vermeiden. Wir haben uns auch darauf geeinigt, unsere gesamte installierte Sicherheitssoftware zu überprüfen, um zu gewährleisten, dass die richtigen Richtlinien für das nächste Mal vorhanden sind.
Die beste Verteidigung ist ein solider Incident Response-Plan
Dieser Erfahrungsbericht zeigt, wie essenziell ein gut definierter Incident Response-Plan für eine gute Cyberabwehr ist. Er umfasst nicht nur technische Schritte, sondern auch die Klärung von Entscheidungsketten, die Frage, wann ein externer Rechtsbeistand hinzugezogen werden soll und wie mit Kunden, Partnern und der Öffentlichkeit zu kommunizieren ist.
Unternehmen, die nicht genau wissen, wie sie einen umfassenden Plan für die Cyber-Incident Response entwickeln sollen, können auf die Hilfe von Drittanbietern zurückgreifen. Trend Micro hat beispielsweise eine Partnerschaft mit Net Diligence, um Kunden 50 % Rabatt auf den Breach Plan Connect Service des Unternehmens zu gewähren, der bei der Entwicklung von maßgeschneiderten Reaktionsplänen auf Vorfälle hilft.
Die Infografik fasst die fünf wichtigsten Schritte von Incident Response zusammen.