Erstellung eines Plans zur Reaktion auf Vorfälle von Grund auf

Ein Cyberangriff kündigt sich nicht an. Eines Morgens wird ein Alarm ausgelöst, jemand eröffnet ein Ticket, und bis die Führungskräfte informiert werden, breitet sich der Schaden bereits aus. Was Unternehmen, die einen Sicherheitsvorfall innerhalb weniger Stunden eindämmen können, von denen unterscheidet, die monatelang mit der Wiederherstellung beschäftigt sind, ist nicht bessere Technologie. Es ist die Vorbereitung. Genauer gesagt: ob es bereits einen Plan gab, bevor etwas schiefging.

Ein Incident-Response-Plan (IRP) ist ein dokumentiertes, erprobtes Verfahren zur Erkennung, Eindämmung und Bewältigung von Sicherheitsvorfällen. Das klingt bürokratisch. In der Praxis macht es jedoch den Unterschied zwischen einer kontrollierten Reaktion und organisiertem Chaos um 2 Uhr morgens aus.

Was gilt eigentlich als Vorfall?

Nicht jede Warnmeldung ist ein Vorfall. Ein fehlgeschlagener Anmeldeversuch ist nur „Rauschen“. Ransomware, die einen Dateiserver verschlüsselt, hingegen nicht. Diese Unterscheidung ist wichtig, da sie darüber entscheidet, wer wann und wie schnell eingeschaltet wird.

Allgemeine Kategorien, die es zu definieren gilt, bevor etwas passiert:

• Datenschutzverletzung: unbefugter Zugriff auf sensible oder regulierte Daten
• Malware-Infektion: Ransomware, Spyware, Wiper, Trojaner
• Denial-of-Service: Angriffe, die Systeme beeinträchtigen oder lahmlegen
• Interne Bedrohung: böswillige oder versehentliche Handlungen von Mitarbeitern oder Auftragnehmern
• Kompromittierung der Lieferkette: Angriffe über Software von Anbietern (SolarWinds ist hierfür das Paradebeispiel)
• Unbefugter Zugriff: Diebstahl von Anmeldedaten, Ausweitung von Berechtigungen, laterale Bewegung

Eine Phishing-E-Mail, auf die geklickt wurde, die aber keinen Schaden angerichtet hat, unterscheidet sich von einer, durch die ein Cobalt-Strike-Beacon installiert wurde. Der Plan muss beide Fälle abdecken und dem Team schnell mitteilen, um welchen Fall es sich handelt.

Warum die meisten Pläne in der Praxis nicht funktionieren

Viele Organisationen verfügen über ein Dokument zur Reaktion auf Vorfälle. Weitaus weniger haben jedoch eines, das tatsächlich jemand gelesen hat. Und noch weniger haben es anhand eines Szenarios getestet, das einem realen Fall nahekommt.

Die üblichen Probleme: Das Dokument ist drei Jahre alt, es enthält Kontaktdaten von Mitarbeitern, die das Unternehmen bereits verlassen haben, es geht von Tools aus, die inzwischen ersetzt wurden, und niemand aus dem eigentlichen Notfallteam hat es je gesehen. Es zeigt sich, dass es einen erheblichen Unterschied zwischen einem Richtliniendokument und einem operativen Leitfaden gibt. Das eine stellt die Prüfer zufrieden. Das andere ist das, was man braucht, wenn um 3 Uhr morgens die Produktion ausfällt und niemand weiß, wer befugt ist, einen kompromittierten Server vom Netz zu nehmen.

Die sechs Phasen und was sie in der Praxis bedeuten

Das NIST SP 800-61 -Rahmenwerk unterteilt die Reaktion auf Sicherheitsvorfälle in sechs Phasen. SANS verwendet eine ähnliche Logik mit anderen Bezeichnungen. In jedem Fall bleibt die Struktur bestehen.

Vorbereitung

Alles, was vor einem Vorfall geschieht. Hier findet die eigentliche Arbeit statt: die Definition dessen, was ein Vorfall ist, der Aufbau und die Schulung des Reaktionsteams, die Einrichtung der Protokollierungs- und Warninfrastruktur sowie die Durchführung von Tabletop-Übungen. Ein Detail, das ständig übersehen wird: die Vorabgenehmigung von Maßnahmen. Während eines laufenden Vorfalls kostet das Warten auf die rechtliche Freigabe zur Isolierung eines Servers Zeit, die Sie nicht haben. Legen Sie im Voraus fest, was sofort und von wem ohne Eskalation getan werden darf.

Identifizierung

Es ist etwas passiert. Die Frage ist nur, was genau. In dieser Phase geht es darum, Warnmeldungen in bestätigte Vorfälle umzuwandeln, Signale aus SIEM- und EDR-Tools miteinander zu verknüpfen, den Umfang zu ermitteln und einen Zeitablauf zu erstellen. Die Geschwindigkeit hängt hier direkt von der Qualität der Protokollierung ab, die während der Vorbereitung eingerichtet wurde. Unbrauchbare Protokolle bedeuten eine langsame Identifizierung. Eine langsame Identifizierung bedeutet weniger Handlungsmöglichkeiten.

Eindämmung

Kurzfristige Eindämmungsmaßnahmen sind schnell und drastisch: Infizierte Rechner isolieren, IP-Adressen der Angreifer sperren, kompromittierte Konten deaktivieren. Langfristige Eindämmungsmaßnahmen sind gezielter: vorübergehende Korrekturen, Neukonfiguration von Systemen, verstärkte Überwachung bestimmter Verhaltensmuster. Eine Entscheidung, die immer wieder auftaucht: Sofort die Verbindung trennen oder den Angreifer zunächst beobachten? Das Trennen der Verbindung begrenzt den Schaden. Die Überwachung deckt das gesamte Ausmaß auf. Für beides gibt es stichhaltige Argumente. Diese Entscheidung sollte im Voraus besprochen werden und nicht unter Druck improvisiert werden.

Ausrottung

Beseitigen Sie die Bedrohung vollständig. Schließen Sie die Sicherheitslücke, die ausgenutzt wurde, löschen Sie Malware und Persistenzmechanismen, ändern Sie Zugangsdaten und stellen Sie kompromittierte Systeme anhand sauberer Images wieder her. Wenn dieser Schritt übersprungen oder überstürzt durchgeführt wird, werden Unternehmen zwei Wochen später über denselben Angriffsvektor erneut kompromittiert. Das passiert häufiger, als in der Öffentlichkeit bekannt wird.

Erholung

Stellen Sie die Dienste in der Reihenfolge ihrer Priorität wieder her. Vergewissern Sie sich, dass die Systeme fehlerfrei sind, bevor Sie sie wieder anschließen. Beobachten Sie den Vorgang genau, um wiederkehrende Probleme zu erkennen. Und kommen Sie Ihren Meldepflichten nach – gemäß DSGVO müssen Sie die Aufsichtsbehörden innerhalb von 72 Stunden nach einer Verletzung des Schutzes personenbezogener Daten benachrichtigen. Diese Frist läuft weiter, auch wenn die Wiederherstellung noch im Gange ist.

Gewonnene Erkenntnisse

Die Phase, die die meisten Teams überspringen, weil sie erschöpft sind. Und genau deshalb ist sie so wichtig. Eine Nachbesprechung nach einem Vorfall sollte innerhalb von zwei Wochen stattfinden: Was ist passiert, was hat funktioniert, was nicht, welche Lücken sind zutage getreten, welche Änderungen werden vorgenommen und bis wann? Dokumentieren Sie dies. Aktualisieren Sie den Plan. Setzen Sie die Änderungen dann auch tatsächlich um; sonst war es nur ein Treffen.

Tools, die einen Plan umsetzbar machen

Der IRP beschreibt, was zu tun ist. Werkzeuge sorgen dafür, dass dies auch unter Zeitdruck zügig umgesetzt wird.

• SIEM: Splunk, Microsoft Sentinel, IBM QRadar für die Log-Korrelation in großem Maßstab
• EDR: CrowdStrike Falcon, SentinelOne, Microsoft Defender zur Erkennung von verdächtigem Verhalten und zur Isolierung von Endgeräten
• SOAR: Palo Alto XSOAR, Splunk SOAR für die automatisierte Ausführung von Playbooks
• Bedrohungsinformationen: MISP, Recorded Future – Hintergrundinformationen zu den TTPs der Angreifer
• Forensik: Velociraptor, Magnet AXIOM, Volatility für Ermittlungen und die Sicherung von Beweismitteln

Die Tools sind weniger wichtig als die Frage, ob die Mitarbeiter wissen, wie man sie unter Druck einsetzt. Eine Splunk-Instanz mit 400 Dashboards und ohne Runbooks nützt niemandem etwas.

Wissenswertes zur Angleichung der Rechtsvorschriften

Je nach Branche und Region ist ein IRP keine Option, sondern gesetzlich vorgeschrieben. Wichtige Rahmenbedingungen:

• NIST SP 800-61 Rev. 2: Die Richtlinie für US-Bundesbehörden und die meisten Unternehmensumgebungen
• ISO/IEC 27035: Internationale Norm für das Vorfallmanagement
• Artikel 33 der DSGVO: 72-Stunden-Meldepflicht bei Datenschutzverletzungen in Bezug auf personenbezogene Daten aus der EU
• NIS2-Richtlinie: Meldepflichten bei Sicherheitsvorfällen für Betreiber kritischer Infrastrukturen in der gesamten EU
• DORA: Anforderungen an die Widerstandsfähigkeit des EU-Finanzsektors, die seit Januar 2025 gelten und ausdrückliche Vorschriften für Stresstests enthalten
• PCI DSS v4.0: Dokumentations- und jährliche Testanforderungen für den Zahlungsverkehrssektor

NIS2 und DORA sind es, die Unternehmen derzeit unvorbereitet treffen. Beide legen die Messlatte in Bezug auf Dokumentation, Testhäufigkeit und Meldefristen deutlich höher.

Anbieter, die eine Überlegung wert sind

Manche Organisationen bauen ihre IR-Kapazitäten vollständig intern auf. Die meisten verfügen jedoch nicht über das erforderliche Personal oder die nötige Erfahrung, um dies erfolgreich umzusetzen, insbesondere im Bereich Simulation und Test. Hier eine kurze Auflistung:

DXC Technology deckt die gesamte Entwicklung von IR-Programmen ab: Konzeptentwicklung, Tabletop-Übungen sowie Managed Detection and Response. Das Unternehmen ist besonders stark in regulierten Branchen (Energie, Gesundheitswesen, Finanzdienstleistungen) vertreten, einschließlich Softwarelösungen für die Energiebranche, bei denen die Einhaltung gesetzlicher Vorschriften von Beginn an in das Projekt integriert ist.

Secureworks (Atlanta) bietet neben seiner Taegis-XDR-Plattform auch IR-Retainer-Dienstleistungen an. Die „Counter Threat Unit“ des Unternehmens veröffentlicht regelmäßig Bedrohungsinformationen, die direkt in die Aktualisierungen der Playbooks einfließen – eine nützliche Funktion für Teams, die Erkennung und Reaktion in einer einzigen Umgebung vereinen möchten.

WithSecure (Helsinki) verfolgt bei der Entwicklung von IR-Programmen einen beratenden Ansatz, der sich stark an den europäischen regulatorischen Anforderungen orientiert. Dies eignet sich besser für Unternehmen, die zum ersten Mal IR-Kapazitäten aufbauen, als für solche, die einen reinen Managed Service suchen.

Trustwave (Chicago) kombiniert Managed Security Services mit IR-Beratung durch SpiderLabs, ein internes Red Team, das in den letzten zehn Jahren einige der detailliertesten Bedrohungsberichte der Branche erstellt hat.

Orange Cyberdefense (Frankreich) übernimmt die grenzüberschreitende IR-Koordination in mehreren EU-Ländern gleichzeitig. Dies ist besonders nützlich für multinationale Unternehmen, die ihre Verpflichtungen gemäß NIS2 und DSGVO parallel in verschiedenen Ländern erfüllen müssen.

Die Fehler, die immer wieder auftreten

Selbst gut vorbereitete Teams machen vorhersehbare Fehler. Die häufigsten davon sind:

• Den Plan nicht zu testen: Ein Dokument, das noch nie unter simulierten Belastungsbedingungen durchgespielt wurde, ist reine Spekulation.
• Keine festgelegten Kommunikationsprotokolle: Wer spricht mit der Presse, wer ruft die Aufsichtsbehörde an, wer informiert die Kunden?
• Davon ausgehen, dass die Backups fehlerfrei sind, ohne sie zu überprüfen
• Dritte außen vor lassen: Cloud-Anbieter, SaaS-Anbieter und MSPs müssen in den Prozess eingebunden werden und dürfen nicht erst im Nachhinein benachrichtigt werden
• IR als reine IT-Aufgabe zu betrachten: Rechtsabteilung, Kommunikation, Personalwesen und Führungsebene spielen bei einem schwerwiegenden Vorfall alle eine Rolle

Und der größte Fehler: den Plan als einmaliges Projekt zu betrachten. Bedrohungen ändern sich. Systeme ändern sich. Mitarbeiter verlassen das Unternehmen. Ein IRP, der nicht aktiv gepflegt wird, ist bereits veraltet, bevor er überhaupt gebraucht wird.

Häufig gestellte Fragen

Wie lange dauert es, ein funktionsfähiges IRP von Grund auf neu zu entwickeln?

Ein Grundkonzept lässt sich in vier bis sechs Wochen ausarbeiten. Ein ausgereiftes Programm mit Leitfäden, erprobten Übungen und der Integration von Tools dauert realistisch gesehen drei bis sechs Monate.

Wie oft sollte es getestet werden?

Mindestens einmal jährlich. DORA und die meisten Unternehmens-Frameworks sehen mittlerweile zweimal jährlich Tabletop-Übungen vor, wobei mindestens einmal eine vollständige Simulation durchgeführt werden soll. Nach jedem größeren Vorfall oder einer wesentlichen Systemänderung ist eine sofortige Überprüfung erforderlich.

Was ist der Unterschied zwischen einer Tabletop-Übung und einer Red-Team-Übung?

Bei einem Tabletop-Szenario steht die Diskussion im Vordergrund; es werden Szenarien durchgespielt, ohne dass dabei Systeme berührt werden. Bei einem Red-Team-Einsatz werden Angreifertechniken aktiv gegen reale Infrastrukturen simuliert. Beide Ansätze sind wertvoll und dienen dazu, unterschiedliche Aspekte zu testen.

Was ist die erste Maßnahme, wenn ein Vorfall bestätigt wird?

Aktivieren Sie das Einsatzteam, dokumentieren Sie den Zeitpunkt und die ersten Anzeichen und leiten Sie die vorab genehmigten Eindämmungsmaßnahmen ein. Berühren Sie infizierte Systeme nicht, um sie zu bereinigen, bevor die forensischen Beweise gesichert sind; erst diese Informationen geben Aufschluss über das gesamte Ausmaß des Vorfalls.

• Über
• Neueste Beiträge

Milena Baghdasaryan

Content-Spezialist bei PowerDMARC

Milena ist eine erfahrene Autorin und Inhaltserstellerin mit mehr als 7 Jahren Erfahrung in der Erstellung ansprechender Inhalte über IT, Cybersicherheit, virtuelle Veranstaltungen und mehr. Sie hat eine nachgewiesene Erfolgsbilanz bei der Erstellung hochwertiger Arbeiten für internationale Magazine und ist Absolventin renommierter Institutionen wie der New York University Abu Dhabi, UWC China und dem College of Europe.

Neueste Beiträge von Milena Baghdasaryan (alle anzeigen)

• Erstellung eines Plans zur Reaktion auf Vorfälle von Grund auf – 8. September 2026
• Die neue Masche, mit der Hacker Finanz-KI-Assistenten austricksen – 7. September 2026
• Bewährte Verfahren für die DNS-Sicherheit: Eine umfassende Checkliste zur Absicherung – 7. September 2026