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?“
Warum Sie einen Incident Response-Plan benötigen
Es ist von entscheidender Bedeutung, dass ein Unternehmen über einen Incident Response-Plan verfügt, damit in der Hochdrucksituation eines Vorfalls die richtigen Entscheidungen getroffen werden können, um die Situation wieder unter Kontrolle zu bringen. Ein Ereignis im Bereich der Cyber-Security kann eine sehr beängstigenden Situation sein, und wenn die Reaktion nicht komplett koordiniert erfolgt, dann können die Konsequenzen den Ruf einer Marke schwer beschädigen. Um ein Cyber-Security-Ereignis effektiv bearbeiten zu können, benötigt Ihr Unternehmen ein Team, das auf die Ereignisreaktion spezialisiert ist. Einige Unternehmen nennen dieses Team das Computer Security Incident Response Team (CSIRT) – es gibt weitere Spielarten dieses Akronyms wie Security Incident Response Team (SIRT) oder Computer Incident Response Team (CIRT). Die Mission dieses Teams ist dieselbe, egal wie Sie es nennen – den Vorfallsreaktionsplan des Unternehmens umzusetzen, wenn das Fledermauslogo am Himmel erstrahlt. Wenn Sie im Bereich Datensicherheit tätig sind, haben Sie täglich mit Sicherheitsvorfällen zu tun. Gelegentlich wächst sich ein kleines Sicherheitsproblem zu einer echten Paniksituation aus. Weiß jeder, was zu tun ist, wenn das Fledermauslogo aufleuchtet? Kennt jedes CSIRT-Mitglied seine Rolle und Zuständigkeiten und befolgt den freigegebenen Plan? Wenn es viel zu verlieren gibt und der Druck zunimmt, wird das CSIRT so reagieren, wie es geübt hat. Wenn es keinen Plan gibt, kann nicht garantiert werden, dass das Team die passende Reaktion auf einen Cyber-Security-Vorfall findet. Es reicht jedoch nicht aus, nur einen Vorfallsreaktionsplan zu haben: Das CSIRT-Team muss über die notwendigen Fähigkeiten und Erfahrungen verfügen, um mit einer potenziell hoch belastenden Situation wie dieser umzugehen. Experten für digitale Forensik, Malware-Analysten, Vorfalls-Manager und SOC-Analysten müssen komplett einbezogen werden und die Situation an vorderster Front unter Kontrolle bringen. Dazu gehört auch, wichtige Entscheidungen zu treffen, eine eingehende Untersuchung durchzuführen, den wichtigsten Interessenvertretern Feedback zu geben und schließlich der Unternehmensleitung mitzuteilen, dass die Situation unter Kontrolle ist. Hinzu kommt, dass Zeit häufig extrem knapp ist. Es gibt immer mehr gesetzliche Auflagen über die Meldung von Datenlecks: So verlangt beispielsweise die DSGVO, dass Unternehmen Datenschutzereignisse innerhalb von 72 Stunden nach deren Entdeckung melden müssen. Meine Erfahrung bei der Arbeit an Cybersicherheitsereignissen hat mir gezeigt, wie wertvoll ein Plan zur Reaktion darauf ist. Es ist schon vorgekommen, dass ich in den frühen Morgenstunden zu einem Vorfall gerufen wurde, um festzustellen, dass ein Cybersicherheitsereignis vorliegt. Der CEO muss sich auf das CSIRT verlassen können, um Antworten und Anleitung darüber zu erhalten, wie eine Katastrophe verhindert werden kann. Der Ereignisreaktionsplan sorgt dafür, dass die richtigen Leute mit den richtigen Fähigkeiten und Erfahrungen bereit stehen und dass sie wissen, was von ihnen erwartet wird und welche Verfahren befolgt werden müssen, um die Bedrohung erfolgreich einzudämmen und zu beseitigen. Eine solche Struktur zu haben, hat sich jedes Mal als extrem wertvoll erwiesen.
Überlegungen zur Planung der Incident Responses
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.
- WICHTIGER TIPP: Eine Triage-Matrix gibt Aufschluss über den Schweregrad eines Ereignisses, so dass dieses schnell und korrekt priorisiert werden kann.
Pläne und Verfahren sind wichtig. Vor allem ist es jedoch das CSIRT, das den Incident Response-Plan ausführen wird und für die Wiederherstellung nach dem Ereignis verantwortlich ist. Die richtigen Mitarbeiter und Fähigkeiten müssen vorhanden sein, damit die Incident Responses erfolgreich durchgeführt werden kann. Das CSIRT wird aus verschiedenen Teams bestehen, und jede Rolle ist enorm wichtig, wenn es darum geht, aus einem Ereignis eine Erfolgsgeschichte statt einer potenziellen Katastrophe zu machen. Das CSIRT ist eine Mischung aus erfahrenem technischen und nichttechnischen Personal, das zusammenarbeitet, um das Ausmaß des Ereignisses zu verstehen und zu ermitteln, wie es schließlich behoben und der Schaden begrenzt werden kann. Die richtigen Leute müssen eingestellt und in die richtige Position gebracht werden. Automatisierung ist auch entscheidend für die Planung der Incident Responses. Indem die vorhandenen Sicherheitstools sowie deren Kapazitäten und Umfang verstanden werden, wird ein gewisses Maß an Automatisierung ermöglicht. Fein abgestimmte Sicherheitskontrollen stellen sicher, dass Ihre erste Verteidigungslinie – das Sicherheitsbetriebszentrum (SOC, Security Operations Center) – auf Alarme reagiert, die aussagekräftig und legitim sind. Zuverlässige und fein abgestimmte Alarme zu haben bedeutet, dass einige Bereiche des Incident Response-Prozesses automatisch eingeleitet werden können und dass die erste Triage und die Beweiserfassung für ein Ereignis automatisch generiert werden kann. Wenn Ihre Automatisierung eine große Anzahl falsch-positiver Ergebnisse erzeugt, führt das einerseits zu Ermüdung in einem Schlüsselbereich Ihres Incident Response-Plans und erhöht andererseits die Wahrscheinlichkeit, dass Sie einen wichtigen Alarm verpassen, wenn er im Lärm der falsch-positiven Ergebnisse untergeht. Neben einemIncident Response-Plan muss ein Unternehmen auch die Erstellung eines Wiederherstellungsplan in Betracht ziehen. Während ein Incident Response-Plan dazu dient, die Bedrohung durch ein Ereignis zu beheben, ist ein Wiederherstellungsplan dafür vorgesehen, den Betrieb eines Unternehmens wiederherzustellen und es nach einer größeren Katastrophe, ob natürlich oder menschengemacht, wieder online zu bringen. Wenn das Unternehmen nicht funktionieren kann, umreißt der Wiederherstellungsplan die Schritte, die erforderlich sind, um das Unternehmen wieder online zu bringen. Ein Unternehmen muss unter Umständen auch berücksichtigen, ob es vom Payment Card Industry Data Security Standard (PCI DSS, zu Deutsch: Datensicherheitsstandard der Zahlungskartenindustrie) betroffen ist. Dieser gilt, wenn ein Unternehmen Aufzeichnungen von Kunden-Kreditkartendaten verarbeitet, speichert oder übermittelt.
Wer innerhalb eines Incident Response-Plans verantwortlich ist
Das CSIRT setzt sich aus spezialisierten Teams zusammen, denen jeweils eine wichtige Rolle bei der Handhabung eines Ereignisses zukommt. Die Sicherheitsbetriebszentren (SOCs) sind die erste Verteidigungslinie. Sie sind 24 Stunden am Tag und 7 Tage die Woche an vorderster Front im Einsatz. Ihre Aufgabe ist es, jeden Sicherheitsalarm zu priorisieren, Beweise zu sammeln und geeignete Maßnahmen festzulegen. Die SOC-Analytiker, die im Schichtbetrieb arbeiten, müssen über ein breites Verständnis von Cyber-Sicherheitsbedrohungen verfügen. Sie erhalten Zugang zu verschiedenen Sicherheitsplattformen und -tools wie SIEM (Security Incident Event Manager) und EDR (Endpoint Detection & Response). Diese Tools können eine Vielzahl von Alarmen erzeugen, die von DDoS-Angriffen bis hin zu bösartigen Befehlen reichen können, die auf einem Gerät ausgeführt werden. Die SOC-Analytiker müssen diese Daten verstehen und interpretieren können. Wenn einem Ereignis eine hohe Priorität zukommt oder es nicht in den Kompetenzbereich des SOC fällt, ist ihr Eskalationspunkt das Ereignismanagementteam. Ein Kollege hat einmal die Aufgabe eines Ereignismanagers als „Die Kunst des Katzenhütens“ beschrieben. Ihre Aufgabe besteht darin, die Arme um ein Ereignis zu legen, die wichtigsten Interessenvertreter mit einzubeziehen und die Diskussion voranzutreiben, um den besten Aktionsplan zu ermitteln. Das Ereignismanagementteam sind die Generäle: Sie erhalten Beweise, Ratschläge und Meinungen und legen das Tempo eines Ereignisses fest. Sie bestimmen, welche Aufgaben zu erledigen sind, durch wen und bis wann. Alle zu planenden Anrufe und Kommunikationen zu Ereignissen, werden vom Ereignismanagement erledigt. Das CIRT-Team sind die Spezialeinheiten. Sie sind nur an hochrangigen und sehr wichtigen Ereignissen beteiligt, und wenn sie gerade nicht an Ereignissen arbeiten, verfeinern und entwickeln sie ihre Fähigkeiten. Während die SOC-Analysten über ein breites Spektrum an Fähigkeiten verfügen müssen, besteht das CIRT-Team eher aus Personen mit speziellen Fähigkeiten und Interessen, beispielsweise Malware-Analysten und Digitalforensik-Experten. Dieses Team bietet fachkundige technische Beratung und Analyse und wird vom Ereignismanagement mit Aufgaben betraut, die nicht vom SOC durchgeführt werden können. Das Bedrohungsdaten-Team sind die Aufklärungsdivision, die die Cyber-Bedrohungslandschaft bewerten und verstehen. Wenn der Vorfall einen kompromittierten Server betrifft, der vertrauliche Daten enthält, dann durchsuchen sie das Darkweb nach Beweisen dafür, dass die Daten zum Verkauf angeboten werden. Wenn sich der Vorfall auf eine Malware-Infektion bezieht, führt das Bedrohungsdaten-Team eine sog. OSINT (Open Source Intelligence, z. Dt. Open-Source-Aufklärung) über die Malware-Familie durch und berät über die Wahrscheinlichkeit, dass es sich dabei um einen gezielten Angriff auf Ihr Unternehmen handelt.
6 Schritte zur Erstellung eines Incident Response-Plans
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.
1. Vorbereitung
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.
2. Identifizierung
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.
3. Eindämmung
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.
4. Beseitigung
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.
5. Wiederherstellung
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.
6. Rückblick und Schlussfolgerungen
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.
Best Practices für den Incident Response-Plan
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.
{}Incident Response-Plan{}
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.
Was ist nach einem Cyber-Vorfall zu tun?
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.
