Montagmorgen, 07:42 Uhr.

Das Monitoring meldet ungewöhnlich viele Dateiänderungen auf einem zentralen Fileserver. Wenige Sekunden später schlägt das EDR-System auf mehreren Clients Alarm. Gleichzeitig gehen beim Helpdesk die ersten Anrufe ein:

„Meine Dateien lassen sich nicht mehr öffnen.“

Was jetzt?

Server ausschalten?

Netzwerkverbindungen trennen?

Geschäftsführung informieren?

Backups zurückspielen?

Polizei anrufen?

Systeme neu installieren?

Oder erst einmal herausfinden, was überhaupt passiert ist?

Genau für diese Situation benötigt eine Organisation einen vorbereiteten Incident-Response-Prozess.

Denn während eines Cyberangriffs fehlt vor allem eines:

Zeit.

Wer Verantwortlichkeiten, Meldewege und technische Erstmaßnahmen erst diskutiert, wenn bereits Systeme verschlüsselt werden, verliert wertvolle Minuten oder Stunden.

NIS-2 macht Incident Response deshalb zu einem wesentlichen Bestandteil eines systematischen Cyber-Risikomanagements.

Das Ziel lautet nicht nur, Angriffe möglichst zu verhindern.

Eine Organisation muss auch vorbereitet sein, wenn Schutzmaßnahmen versagen.

Was ist ein Sicherheitsvorfall?

Nicht jede Warnmeldung ist automatisch ein Sicherheitsvorfall.

Ein Benutzer, der sein Kennwort dreimal falsch eingibt, verursacht zunächst ein Ereignis.

10.000 fehlgeschlagene Anmeldeversuche gegen verschiedene Benutzerkonten innerhalb weniger Minuten können dagegen auf einen Angriff hindeuten.

Deshalb sollten verschiedene Begriffe unterschieden werden.

Security Event

Ein Ereignis mit möglicher Sicherheitsrelevanz.

Beispiele:

• fehlgeschlagene Anmeldung,
• Firewall blockiert Verbindung,
• Malware-Datei erkannt,
• ungewöhnlicher Prozess gestartet.

Security Alert

Ein Sicherheitssystem bewertet ein Ereignis oder mehrere Ereignisse als verdächtig.

Beispielsweise:

„Mögliche Brute-Force-Attacke erkannt.“

Security Incident

Die Analyse ergibt, dass tatsächlich eine Beeinträchtigung oder konkrete Gefährdung der Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen beziehungsweise Systemen vorliegt.

Beispiele:

• kompromittiertes Benutzerkonto,
• Malware-Infektion,
• Ransomware,
• Datenabfluss,
• erfolgreicher unbefugter Zugriff,
• manipuliertes System,
• erfolgreicher Angriff auf einen Server.

Diese Unterscheidung verhindert, dass jedes technische Ereignis sofort eine vollständige Krisenorganisation auslöst.

1. Der Incident-Response-Lebenszyklus

Ein Incident-Response-Prozess lässt sich vereinfacht in mehrere Phasen unterteilen:

Vorbereitung
     │
     ▼
Erkennung
     │
     ▼
Analyse
     │
     ▼
Eindämmung
     │
     ▼
Beseitigung
     │
     ▼
Wiederherstellung
     │
     ▼
Lessons Learned

Dabei wird schnell deutlich:

Incident Response beginnt nicht erst mit dem Angriff.

Die wichtigste Phase findet vorher statt:

Vorbereitung.

2. Vorbereitung auf Sicherheitsvorfälle

Vor einem Vorfall sollten mindestens folgende Fragen beantwortet sein:

• Wer darf einen Sicherheitsvorfall feststellen?
• Wer übernimmt die technische Leitung?
• Wer entscheidet über das Abschalten kritischer Systeme?
• Wer informiert die Leitung?
• Wer bewertet mögliche Meldepflichten?
• Wer kommuniziert mit externen Stellen?
• Welche Dienstleister unterstützen im Notfall?
• Wo befinden sich Kontaktdaten?
• Welche Systeme sind besonders kritisch?

Diese Informationen gehören in einen dokumentierten Incident-Response-Plan.

Der Plan sollte außerdem verfügbar sein, wenn zentrale IT-Systeme gerade nicht funktionieren.

Ein ausschließlich im möglicherweise verschlüsselten Fileserver gespeicherter Notfallplan besitzt im Ernstfall einen gewissen Unterhaltungswert – aber wenig praktischen Nutzen.

3. Incident-Response-Team festlegen

Für größere Sicherheitsvorfälle sollte ein definiertes Team existieren.

Je nach Organisation können daran beteiligt sein:

IT-Betrieb

Verantwortlich für technische Systeme und Infrastruktur.

Informationssicherheit

Bewertung und Koordination des Sicherheitsvorfalls.

Datenschutz

Einbindung bei möglichen Verletzungen des Schutzes personenbezogener Daten.

Geschäftsführung beziehungsweise Behördenleitung

Entscheidungen mit organisatorischer oder strategischer Tragweite.

Kommunikation beziehungsweise Pressestelle

Interne und externe Kommunikation.

Rechtsabteilung

Bewertung rechtlicher Auswirkungen.

Externe Spezialisten

Beispielsweise:

• Incident-Response-Dienstleister,
• Forensiker,
• Hersteller,
• IT-Dienstleister.

Nicht jede Organisation benötigt ein eigenes 24/7-CSIRT.

Sie muss jedoch wissen, wer im Ernstfall welche Aufgabe übernimmt.

4. Meldewege müssen eindeutig sein

Ein Mitarbeiter bemerkt etwas Verdächtiges.

Was nun?

Eine schlechte Antwort wäre:

„Schreib mal irgendwem aus der IT.“

Eine Organisation benötigt eindeutige interne Meldewege.

Beispielsweise:

Mitarbeiter
    │
    ▼
Service Desk / Security
    │
    ▼
Erste Bewertung
    │
    ├── kein Incident
    │
    └── Incident
           │
           ▼
Incident Manager
           │
           ├── IT
           ├── Informationssicherheit
           ├── Datenschutz
           └── Leitung

Für kritische Vorfälle müssen zusätzlich Eskalationswege außerhalb der normalen Arbeitszeiten definiert sein.

Ein Ransomware-Angriff hält sich schließlich nur selten an Kernarbeitszeiten.

5. Sicherheitsvorfälle klassifizieren

Nicht jeder Incident benötigt dieselbe Reaktion.

Eine mögliche Klassifizierung könnte lauten:

Niedrig

Begrenztes Ereignis ohne wesentliche Auswirkungen.

Beispiel:

Malware auf einem einzelnen isolierten Client, erfolgreich blockiert.

Mittel

Mehrere Systeme betroffen oder potenziell relevante Auswirkungen.

Hoch

Kritische Systeme betroffen, erhebliche Betriebsbeeinträchtigung oder möglicher Datenabfluss.

Kritisch

Massiver Angriff mit erheblichen Auswirkungen auf zentrale Dienste oder die gesamte Organisation.

Beispiele:

• großflächige Ransomware,
• kompromittierte zentrale Identitätsinfrastruktur,
• erheblicher Datenabfluss,
• Ausfall kritischer Dienste.

Die Klassifizierung kann anschließend automatisch Eskalations- und Kommunikationsprozesse auslösen.

6. Erstmaßnahmen – die ersten Minuten entscheiden

Nach der Bestätigung eines Sicherheitsvorfalls müssen möglicherweise schnell Maßnahmen getroffen werden.

Dabei gilt:

Eindämmen – aber nicht kopflos handeln.

Mögliche Erstmaßnahmen können sein:

• kompromittierten Client vom Netzwerk isolieren,
• Benutzerkonto sperren,
• verdächtige Netzwerkverbindung blockieren,
• Firewallregel setzen,
• kompromittierten Dienst deaktivieren,
• schädliche Domain blockieren,
• betroffene Systeme segmentieren,
• Zugangsdaten zurücksetzen.

Ein EDR-System kann beispielsweise einen kompromittierten Rechner logisch vom Netzwerk isolieren, ohne ihn vollständig herunterzufahren.

Das kann für spätere Untersuchungen wertvoll sein.

7. Nicht sofort alles ausschalten

Bei einem Cyberangriff besteht häufig der erste Impuls:

„Stecker raus!“

Das kann richtig sein.

Es kann aber auch wertvolle Beweise vernichten.

Im Arbeitsspeicher können beispielsweise vorhanden sein:

• laufende Prozesse,
• Netzwerkverbindungen,
• Malware,
• Verschlüsselungsschlüssel,
• Zugangsdatenfragmente,
• Informationen über den Angreifer.

Wird das System ausgeschaltet, gehen volatile Daten verloren.

Deshalb sollte ein Incident-Response-Plan definieren, unter welchen Bedingungen Systeme:

• isoliert,
• heruntergefahren,
• weiter betrieben,
• forensisch gesichert

werden.

Bei einer aktiven Verschlüsselung kann wiederum sofortiges Eingreifen wichtiger sein als die perfekte Beweissicherung.

Incident Response ist deshalb immer eine risikobasierte Entscheidung.

8. Eindämmung – den Angriff stoppen

Die sogenannte Containment-Phase soll verhindern, dass sich ein Angreifer weiter ausbreitet.

Beispielsweise:

kompromittierter Client
        │
        X
     Firewall
        │
        ├── Fileserver
        ├── Datenbank
        ├── Backup
        └── Domaincontroller

Mögliche Maßnahmen sind:

• Netzwerkisolation,
• VLAN-Sperren,
• Firewallregeln,
• Sperren kompromittierter Konten,
• Widerrufen von Sessions oder Tokens,
• Abschalten kompromittierter Dienste,
• Blockieren von Indicators of Compromise.

Dabei sollte besonders darauf geachtet werden, kritische Backup-Infrastrukturen zu schützen.

9. Indicators of Compromise

Während eines Sicherheitsvorfalls werden häufig sogenannte Indicators of Compromise (IoCs) identifiziert.

Dazu können gehören:

• IP-Adressen,
• Domains,
• URLs,
• Datei-Hashes,
• Dateinamen,
• Registry-Einträge,
• Prozesse,
• Benutzerkonten,
• ungewöhnliche Netzwerkverbindungen.

Ein gefundener Indikator kann anschließend in der gesamten Infrastruktur gesucht werden.

Beispiel:

Malware-Hash gefunden
        │
        ▼
SIEM / EDR Suche
        │
        ▼
weitere 14 Systeme betroffen

Dadurch lässt sich der tatsächliche Umfang eines Angriffs besser bestimmen.

10. Forensik – was ist eigentlich passiert?

Nach der ersten Eindämmung beginnt die genauere Untersuchung.

Die zentralen Fragen lauten:

Wie kam der Angreifer hinein?

Welche Systeme wurden kompromittiert?

Wie lange war der Angreifer bereits im Netzwerk?

Welche Konten wurden verwendet?

Welche Daten wurden möglicherweise kopiert?

Welche Systeme wurden verändert?

Dafür können verschiedene Datenquellen ausgewertet werden:

• SIEM-Logs,
• Firewall-Logs,
• EDR-Telemetrie,
• Windows Event Logs,
• Syslog,
• VPN-Logs,
• Proxy-Logs,
• DNS-Logs,
• Cloud-Logs,
• Speicherabbilder,
• Festplattenabbilder.

Hier zeigt sich der Wert der in Teil 13 beschriebenen zentralen Protokollierung.

Was vorher nicht protokolliert wurde, lässt sich hinterher nur schwer rekonstruieren.

11. Beweismittel richtig sichern

Bei schwerwiegenden Vorfällen können forensische Untersuchungen oder rechtliche Schritte erforderlich werden.

Dann muss nachvollziehbar sein:

• Wer hat Beweise gesichert?
• Wann wurden sie gesichert?
• Von welchem System stammen sie?
• Wurden sie verändert?
• Wo werden sie aufbewahrt?

Ein wichtiges Konzept ist die Chain of Custody.

Sie dokumentiert den Umgang mit einem Beweismittel vom Zeitpunkt der Sicherung bis zur späteren Analyse beziehungsweise Übergabe.

Hashes können zusätzlich dabei helfen, die Integrität forensischer Abbilder nachzuweisen.

12. Ursache beseitigen

Nachdem der Angriff verstanden und eingedämmt wurde, muss seine Ursache beseitigt werden.

Diese Phase wird häufig als Eradication bezeichnet.

Maßnahmen können sein:

• Malware entfernen,
• kompromittierte Systeme neu installieren,
• Sicherheitslücken patchen,
• Passwörter ändern,
• Schlüssel erneuern,
• Tokens widerrufen,
• kompromittierte Konten entfernen,
• Persistenzmechanismen beseitigen,
• Firewallregeln anpassen.

Besonders wichtig:

Nicht nur die sichtbaren Symptome beseitigen.

Wenn ein kompromittierter Server neu installiert wird, die ursprünglich ausgenutzte Schwachstelle aber weiterhin vorhanden ist, kann der Angreifer einfach zurückkehren.

13. Wiederherstellung

Erst danach folgt die kontrollierte Rückkehr zum Normalbetrieb.

Hier greifen die Verfahren aus Teil 12 – Backup und Disaster Recovery.

Mögliche Schritte:

System bereinigen / neu aufbauen
          │
          ▼
Patchen und härten
          │
          ▼
Daten wiederherstellen
          │
          ▼
Sicherheit prüfen
          │
          ▼
Monitoring verstärken
          │
          ▼
Produktivfreigabe

Bei Ransomware sollte besonders darauf geachtet werden, keine kompromittierten Systeme oder Backups unkontrolliert zurück in die produktive Infrastruktur zu bringen.

14. Kommunikation während eines Vorfalls

Cybersecurity-Vorfälle sind nicht nur technische Ereignisse.

Sie können schnell zu organisatorischen Krisen werden.

Deshalb benötigt Incident Response auch eine Kommunikationsstrategie.

Interne Kommunikation

Möglicherweise müssen informiert werden:

• Leitung,
• IT,
• Informationssicherheit,
• Datenschutz,
• Fachbereiche,
• Beschäftigte.

Externe Kommunikation

Abhängig vom Vorfall können hinzukommen:

• zuständige Behörden,
• Kunden,
• Bürger,
• Partner,
• Dienstleister,
• Versicherungen,
• Strafverfolgungsbehörden,
• Öffentlichkeit.

Dabei sollte eine zentrale Regel gelten:

Kommunikation muss koordiniert erfolgen.

Widersprüchliche Aussagen verschiedener Stellen können einen ohnehin schwierigen Vorfall zusätzlich verschärfen.

15. Technische Fakten von Vermutungen trennen

Gerade in den ersten Stunden eines Sicherheitsvorfalls ist vieles noch unbekannt.

Deshalb sollte Kommunikation klar unterscheiden zwischen:

bestätigt

und

wird derzeit untersucht.

Eine problematische Aussage wäre:

„Es sind definitiv keine Daten abgeflossen.“

wenn die forensische Untersuchung gerade erst begonnen hat.

Besser wäre:

„Aktuell liegen uns keine bestätigten Erkenntnisse über einen Datenabfluss vor. Die Untersuchung dauert an.“

Incident-Kommunikation sollte sachlich, transparent und belastbar sein.

16. Dokumentation während des Vorfalls

Während eines größeren Sicherheitsvorfalls sollten Entscheidungen und Maßnahmen möglichst genau dokumentiert werden.

Beispielsweise:

07:42  EDR-Alarm
07:45  Incident bestätigt
07:47  Client-Subnetz isoliert
07:51  Incident Manager informiert
08:03  kompromittiertes Konto gesperrt
08:17  weitere Systeme identifiziert
08:31  externe IR-Unterstützung aktiviert

Eine solche Timeline ist später äußerst wertvoll.

Sie unterstützt:

• Forensik,
• Lessons Learned,
• Managementberichte,
• rechtliche Bewertungen,
• regulatorische Meldungen.

17. NIS-2-Meldepflichten berücksichtigen

Bei erheblichen Sicherheitsvorfällen können unter NIS-2 regulatorische Meldepflichten greifen.

Deshalb muss der Incident-Response-Prozess eine Schnittstelle zum Meldeprozess besitzen.

Vereinfacht:

Security Incident
       │
       ▼
Bewertung
       │
       ├── nicht erheblich
       │
       └── erheblich
              │
              ▼
       regulatorischer
         Meldeprozess

Wichtig ist:

Nicht jeder Security Alert ist automatisch ein meldepflichtiger NIS-2-Vorfall.

Die Bewertung muss anhand der geltenden rechtlichen Kriterien erfolgen.

Die konkreten Meldefristen und Abläufe behandeln wir ausführlich im nächsten Teil dieser Serie.

18. Lessons Learned – nach dem Incident ist vor dem Incident

Nach einem Sicherheitsvorfall besteht verständlicherweise der Wunsch:

„Hauptsache, es läuft wieder.“

Damit sollte der Prozess jedoch nicht enden.

Nach Abschluss des Vorfalls sollte eine strukturierte Nachbesprechung stattfinden.

Dabei können folgende Fragen gestellt werden:

• Wie konnte der Angriff erfolgreich sein?
• Wann wurde er erkannt?
• Hätten wir ihn früher erkennen können?
• Haben die Meldewege funktioniert?
• Waren Verantwortlichkeiten eindeutig?
• Waren die Logs ausreichend?
• Haben Backup und Restore funktioniert?
• Waren Kontaktdaten aktuell?
• Welche Sicherheitsmaßnahmen haben funktioniert?
• Welche haben versagt?
• Welche Verbesserungen sind notwendig?

Das Ziel besteht ausdrücklich nicht darin, einen Schuldigen zu finden.

Das Ziel lautet:

Den nächsten Vorfall besser beherrschen.

19. Maßnahmen aus Lessons Learned verfolgen

Eine Lessons-Learned-Sitzung ohne anschließende Maßnahmen bringt wenig.

Deshalb sollten Verbesserungen konkret festgehalten werden.

Beispielsweise:

Finding:
VPN-Anmeldungen wurden nicht ausreichend überwacht.

Maßnahme:
Neue SIEM Detection Rule einrichten.

Verantwortlich:
Security Team

Frist:
30 Tage

Status:
Offen

Damit entsteht ein kontinuierlicher Verbesserungsprozess.

20. Incident Response muss geübt werden

Ein Notfallplan, den niemand jemals ausprobiert hat, besitzt dasselbe Problem wie ein ungetestetes Backup.

Niemand weiß, ob er tatsächlich funktioniert.

Deshalb sollten Incident-Response-Prozesse regelmäßig geübt werden.

Eine einfache Form ist die Tabletop Exercise.

Dabei wird ein fiktiver Sicherheitsvorfall durchgespielt.

Beispielsweise:

Dienstag, 09:15 Uhr: Das EDR meldet Ransomware auf drei Clients. Gleichzeitig ist der zentrale Fileserver nicht mehr erreichbar.

Nun wird gefragt:

Was tun wir?

Das Team arbeitet den Vorfall Schritt für Schritt durch.

21. Tabletop-Übungen

Eine Tabletop-Übung benötigt keine echte Malware und keine abgeschalteten Produktivserver.

Sie testet vor allem:

• Entscheidungswege,
• Rollen,
• Eskalationen,
• Kommunikation,
• Meldewege,
• Notfallpläne.

Während der Übung können zusätzliche Ereignisse eingebaut werden.

Beispielsweise:

09:15 Ransomware entdeckt

09:25 Domaincontroller zeigt Auffälligkeiten

09:40 Backupserver nicht erreichbar

10:00 Presse ruft an

10:15 Hinweise auf Datenabfluss

10:30 Geschäftsführung verlangt Lagebericht

Dadurch wird schnell sichtbar, wo organisatorische Schwachstellen liegen.

22. Technische Übungen

Neben Tabletop-Übungen können technische Szenarien getestet werden.

Beispielsweise:

• kompromittierten Client isolieren,
• Benutzerkonto sperren,
• Firewallblockade durchführen,
• IoC im SIEM suchen,
• Backup wiederherstellen,
• Recovery-Netz aktivieren,
• Notfallkommunikation testen.

Solche Übungen sollten kontrolliert und möglichst in geeigneten Testumgebungen durchgeführt werden.

23. Incident-Response-Playbooks

Für häufige Angriffsszenarien können vorbereitete Playbooks erstellt werden.

Beispiele:

• Ransomware,
• Phishing,
• kompromittiertes Benutzerkonto,
• Malware,
• Datenabfluss,
• DDoS,
• kompromittierter Server,
• verlorenes Gerät.

Ein Ransomware-Playbook könnte beispielsweise enthalten:

Ransomware erkannt
       │
       ▼
System isolieren
       │
       ▼
Security informieren
       │
       ▼
weitere IoCs suchen
       │
       ▼
Ausbreitung prüfen
       │
       ▼
Backups schützen
       │
       ▼
Forensik starten
       │
       ▼
Meldepflicht bewerten

Playbooks reduzieren den Entscheidungsdruck während eines Vorfalls.

24. Kontaktdaten gehören zur Incident Response

Dieser Punkt klingt banal, wird aber häufig unterschätzt.

Im Notfall müssen möglicherweise innerhalb weniger Minuten externe Stellen erreicht werden.

Deshalb sollten aktuelle Kontaktdaten vorhanden sein für:

• Incident-Response-Dienstleister,
• Cloud-Anbieter,
• Internetprovider,
• Softwarehersteller,
• Cyberversicherung,
• Rechtsberatung,
• zuständige Behörden,
• Strafverfolgung.

Die Liste muss regelmäßig überprüft werden.

Die Telefonnummer eines Incident-Response-Dienstleisters hilft wenig, wenn der Vertrag seit zwei Jahren beendet ist.

Praktische NIS-2-Checkliste für Incident Response

Organisation

☐ Existiert ein dokumentierter Incident-Response-Plan?

☐ Sind Rollen und Verantwortlichkeiten definiert?

☐ Gibt es einen Incident Manager beziehungsweise eine vergleichbare Rolle?

☐ Sind interne und externe Kontaktdaten aktuell?

☐ Ist der Plan auch bei einem IT-Ausfall verfügbar?

Erkennung

☐ Sind Security Events, Alerts und Incidents definiert?

☐ Existieren Kriterien zur Klassifizierung?

☐ Sind SIEM, EDR und Monitoring angebunden?

☐ Können betroffene Systeme schnell identifiziert werden?

Meldewege

☐ Wissen Beschäftigte, wie verdächtige Ereignisse gemeldet werden?

☐ Existieren eindeutige Eskalationswege?

☐ Funktionieren diese auch außerhalb der regulären Arbeitszeiten?

☐ Ist der regulatorische Meldeprozess angebunden?

Erstmaßnahmen

☐ Können Clients schnell isoliert werden?

☐ Können Benutzerkonten kurzfristig gesperrt werden?

☐ Können Firewallregeln schnell angepasst werden?

☐ Ist geregelt, wann Systeme abgeschaltet werden dürfen?

☐ Werden Backup-Systeme bei einem Angriff besonders geschützt?

Forensik

☐ Sind relevante Logs verfügbar?

☐ Ist die Zeit auf allen Systemen synchronisiert?

☐ Gibt es Verfahren zur Beweissicherung?

☐ Kann die Integrität gesicherter Daten nachgewiesen werden?

☐ Sind externe Forensiker bei Bedarf kurzfristig erreichbar?

Kommunikation

☐ Gibt es Verantwortlichkeiten für interne Kommunikation?

☐ Ist externe Kommunikation geregelt?

☐ Werden bestätigte Fakten von Vermutungen getrennt?

☐ Existieren alternative Kommunikationswege bei IT-Ausfällen?

Wiederherstellung

☐ Gibt es definierte Recovery-Prozesse?

☐ Sind RPO und RTO bekannt?

☐ Werden wiederhergestellte Systeme vor der Produktivsetzung überprüft?

☐ Existiert ein verstärktes Monitoring nach der Wiederherstellung?

Lessons Learned

☐ Wird jeder größere Vorfall nachbereitet?

☐ Werden Ursachen und Schwachstellen analysiert?

☐ Werden konkrete Verbesserungsmaßnahmen definiert?

☐ Werden Verantwortliche und Fristen festgelegt?

☐ Wird die Umsetzung anschließend kontrolliert?

Übungen

☐ Finden regelmäßig Tabletop-Übungen statt?

☐ Werden technische Incident-Response-Abläufe getestet?

☐ Existieren Playbooks für wichtige Angriffsszenarien?

☐ Werden Erkenntnisse aus Übungen dokumentiert und umgesetzt?

Incident Response entscheidet darüber, wie eine Organisation reagiert, wenn präventive Sicherheitsmaßnahmen nicht ausreichen.

Und genau davon sollte jede realistische Cybersecurity-Strategie ausgehen:

Irgendwann kann etwas passieren.

Dann zählt nicht mehr ausschließlich, welche Firewall eingesetzt wird oder wie viele Security-Produkte installiert wurden.

Entscheidend sind plötzlich ganz andere Fragen:

Wer übernimmt die Führung?

Welche Systeme sind betroffen?

Wie stoppen wir die Ausbreitung?

Welche Konten müssen gesperrt werden?

Welche Beweise müssen gesichert werden?

Wen müssen wir informieren?

Wie stellen wir den Betrieb sicher wieder her?

Ein funktionierender Incident-Response-Prozess beantwortet diese Fragen bevor der Ernstfall eintritt.

Technische Erstmaßnahmen begrenzen Schäden. Forensik hilft, Ursache und Umfang eines Angriffs zu verstehen. Klare Kommunikationswege verhindern Chaos und widersprüchliche Informationen. Lessons Learned sorgen dafür, dass erkannte Schwächen anschließend tatsächlich beseitigt werden.

Und regelmäßige Übungen zeigen, ob der schöne Notfallplan auch außerhalb des PDF-Dokuments funktioniert.

Der vollständige Kreislauf lautet:

Vorbereiten → Erkennen → Analysieren → Eindämmen → Beseitigen → Wiederherstellen → Lernen → Üben

Die vielleicht wichtigste Erkenntnis lautet dabei:

Incident Response beginnt nicht mit dem Sicherheitsvorfall.

Sie beginnt Monate vorher – mit klaren Rollen, funktionierenden Meldewegen, vorbereiteten Playbooks, verfügbaren Kontaktdaten und einem Team, das weiß, was im Ernstfall zu tun ist.