Website Incident Response: Ein Schritt-für-Schritt-Leitfaden für IT-Manager

Wenn eine Unternehmenswebsite manipuliert wird, Schadsoftware verbreitet oder stillschweigend Kundendaten abfließen, entscheidet selten technisches Können darüber, ob es bei einem schlechten Tag bleibt oder zu einem existenzbedrohenden Ereignis wird. Entscheidend ist vielmehr, ob vor dem Vorfall festgelegt wurde, wer in welcher Reihenfolge und mit welchen Zugriffsrechten Entscheidungen trifft. Dieser Leitfaden bietet IT-Managern in kleinen und mittelständischen Unternehmen einen vollständigen, praxisorientierten Incident-Response-Plan für Vorfälle bei Websites und Webanwendungen. Er basiert auf der Struktur von NIST SP 800-61 und ist für Teams von ein bis fünf Personen statt für ein 24/7-SOC konzipiert.

Arbeiten Sie diesen Plan einmal in ruhigen Zeiten durch (ca. ein Arbeitstag), und Sie verfügen über ein gedrucktes Playbook, eine Kontaktkarte und getestete Backups – die drei Artefakte, die bei der Wiederherstellung den Unterschied zwischen einer schnellen Lösung und wochenlangen Ausfällen ausmachen.

Der Lebenszyklus eines Vorfalls

Jedes glaubwürdige Framework verwendet eine Version desselben Ablaufs. Drucken Sie dies aus; es ist das Rückgrat des gesamten Plans:

   +--------------+     +-----------------+     +--------------+
   | 1. PREPARE   | --> | 2. DETECT &     | --> | 3. CONTAIN   |
   |  plan, roles |     |    ANALYZE      |     |  stop spread |
   |  backups     |     |  triage, scope  |     |  preserve    |
   +--------------+     +-----------------+     |  evidence    |
          ^                                     +------+-------+
          |                                            |
   +------+-------+     +-----------------+     +------v-------+
   | 6. LEARN     | <-- | 5. RECOVER      | <-- | 4. ERADICATE |
   |  post-mortem |     |  restore,       |     |  remove      |
   |  fix causes  |     |  monitor,       |     |  cause,      |
   +--------------+     |  notify         |     |  patch       |
                        +-----------------+     +--------------+

Phase 1 — Vorbereitung (jetzt erledigen, nicht erst bei Gefahr)

1.1 Definition von Schweregraden und Entscheidungsbefugnissen

Unklarheit darüber, „wie schlimm es ist“, verschwendet die erste kritische Stunde. Nutzen Sie drei Stufen:

Bestimmen Sie einen Incident Commander (IC) – die Person, die koordiniert, entscheidet und kommuniziert – sowie einen Stellvertreter für Urlaubszeiten. In kleinen Unternehmen ist der IC meist der IT-Manager; entscheidend ist, dass es eine namentlich genannte Person ist, nicht „das Team“.

1.2 Erstellung der Kontaktkarte

Im Ernstfall haben Sie keine Zeit, nach Logins zu suchen. Erstellen Sie eine einseitige Karte (ausgedruckt und im Passwort-Manager hinterlegt) mit:

• Hosting-Anbieter: Support-Telefon/Portal, Kundennummer, wer hat Admin-Zugriff
• Domain-Registrar und DNS-Anbieter: ebenso
• CMS/Plattform-Admin-Accounts und Speicherort der Zugangsdaten
• CDN/WAF-Anbieter (Cloudflare etc.) Zugang
• Policennummer der Cyber-Versicherung und 24h-Hotline, falls versichert
• Externe IR/Forensik-Firma für SEV-1 (jetzt wählen; Retainer sind günstiger als Notfall-Onboarding)
• Kontakt der Datenschutzbehörde (für Schweden: IMY; EU-weite Liste beim EDPB)
• Intern: CEO, PR-Verantwortlicher, Rechtsabteilung

1.3 Backups, die Sie tatsächlich wiederhergestellt haben

Ein Backup, das nie erfolgreich wiederhergestellt wurde, ist eine Hoffnung, keine Sicherheitskontrolle. Anforderungen:

• 3-2-1-Regel: drei Kopien, zwei Medien, eine extern – und die externe Kopie muss offline oder unveränderlich (object-lock / snapshot) sein, da moderne Ransomware zuerst erreichbare Backups löscht.
• Backup-Umfang: Web-Root, Datenbank, Server-Konfiguration (nginx/Apache, cron), TLS-Zertifikate und – oft vergessen – die Umgebungsvariablen/Secrets, die die App zum Starten benötigt.
• Vierteljährliche Restore-Übung: Wiederherstellung auf eine Test-VM, Website starten, einloggen. Stoppen Sie die Zeit. Diese Zahl ist Ihr realistisches Recovery Time Objective, nicht das in der Richtlinie.

1.4 Erkennung, die Sie tatsächlich bemerken

Kleine Teams beobachten keine Dashboards; Alarme müssen zu ihnen kommen. Mindest-Set: Uptime-Monitoring mit Alarmierung, File-Integrity- oder Defacement-Erkennung im Web-Root, Admin-Login-Benachrichtigungen vom CMS sowie externe Überwachung der Sicherheitsposition Ihrer Domain und Zertifikats-/DNS-Änderungen – FortifyNet’s kontinuierliche Überwachung deckt die externe Seite ab und sendet E-Mails bei Änderungen, was genau die Art ist, wie Manipulationen meist spät entdeckt werden.

Phase 2 — Erkennung & Analyse (die erste Stunde)

Wenn ein Alarm oder Bericht eintrifft, führt der IC das Triage-Verfahren durch – schriftlich, in einem dedizierten Kanal (erstellen Sie #incident-YYYYMMDD), da der Zeitverlauf, den Sie jetzt schreiben, später als Post-Mortem und eventuell als rechtlicher Nachweis dient.

Triage-Fragen, in dieser Reihenfolge:

1. Ist es echt? Symptom von einem externen Netzwerk (mobiler Hotspot) reproduzieren – CDN-Caches und Split-DNS täuschen interne Checks oft.
2. Was ist der Umfang? Eine Seite oder die ganze Site? Nur Webserver oder auch Datenbank? Sind Zugangsdaten oder personenbezogene Daten plausibel betroffen? (Diese Antwort startet die DSGVO-Uhr – siehe Phase 5.)
3. Ist es noch aktiv? Live-Traffic vom Angreifer oder Überreste eines vergangenen Ereignisses?
4. Schweregrad festlegen gemäß Tabelle 1.1 und entsprechend benachrichtigen.

Beweisregel ab der ersten Minute: Kopieren Sie Logs sofort vom betroffenen Server (Access Logs, Error Logs, Auth Logs, CMS-Audit-Trail). Angreifer löschen Logs häufig; Hosting-Anbieter rotieren sie innerhalb weniger Tage. Schalten Sie einen Server, für den Sie Forensik benötigen, nicht einfach aus – isolieren Sie ihn stattdessen (siehe unten); Ausschalten zerstört flüchtige Beweise im Arbeitsspeicher.

Phase 3 — Eindämmung

Eindämmung stoppt die Ausbreitung, ohne Beweise zu vernichten. Wählen Sie die am wenigsten destruktive Aktion, die weiteren Schaden verhindert:

• Site verbreitet Malware/Defacement: Versetzen Sie die Seite auf CDN-/Load-Balancer-Ebene in den Wartungsmodus oder blockieren Sie den gesamten Traffic/schalten Sie Sicherheitsabfragen davor. Benutzer sehen eine saubere Hinweisseite; das kompromittierte Original bleibt für die Analyse intakt.
• Kompromittierter Admin-Account: Deaktivieren Sie den Account und rotieren Sie alle Admin-Zugangsdaten und API-Keys – gehen Sie davon aus, dass der Angreifer den Credential-Store geplündert hat. Erzwingen Sie gleichzeitig MFA.
• Kompromittierung auf Server-Ebene: Isolieren Sie das Netzwerk (Security Group/Firewall: Blocken Sie den gesamten Inbound-Verkehr außer Ihrer Management-IP). Erstellen Sie vor jeder Änderung einen Disk-Snapshot, falls Ihr Host dies unterstützt.
• Datenbank-Exfiltration: Rotieren Sie Datenbank-Passwörter, entziehen Sie externen Zugriff und sichern Sie Query-Logs.

Zwei Eindämmungsfehler, auf die das Team vorbereitet sein sollte: (1) Wiederherstellung vom Backup vor Verständnis des Einstiegspunkts – Sie stellen die Schwachstelle mit den Daten wieder her und werden innerhalb weniger Stunden erneut kompromittiert; (2) Kommunikation über potenziell kompromittierte Infrastruktur – wenn der Mailserver betroffen sein könnte, koordinieren Sie sich über Telefone/Signal.

Phase 4 — Beseitigung

Finden und entfernen Sie die Grundursache, nicht nur das Symptom:

1. Ermitteln Sie den Einstiegspunkt aus den Beweisen: ungepatchtes CMS/Plugin (häufigste Ursache bei SMBs), gestohlene Zugangsdaten, offenes Admin-Panel, unsicheres Upload-Formular oder eine Sicherheitslücke beim Hosting.
2. Neu aufsetzen statt reinigen. Bei jeder Kompromittierung auf Server-Ebene stellen Sie einen neuen Server aus einem bekannten, sauberen Image bereit und migrieren nur verifizierte Daten. Das Reinigen eines gehackten Systems ist unzuverlässig; Webshells verstecken sich in harmlosen Dateien oder Cron-Jobs.
3. Patchen Sie den Einstiegspunkt überall (auch im Staging), aktualisieren Sie alle Komponenten und scannen Sie erneut.
4. Rotieren Sie jedes Secret, das das kompromittierte System lesen konnte: DB-Passwörter, API-Keys, OAuth-Secrets, TLS-Private-Keys, falls Schlüsselmaterial ausgelesen worden sein könnte.

Phase 5 — Wiederherstellung und Benachrichtigung

Technische Wiederherstellung

Stellen Sie den Dienst schrittweise wieder her: Starten Sie die neu aufgebaute Seite hinter dem CDN, führen Sie einen externen Scan durch, um sicherzustellen, dass keine schädlichen Inhalte serviert werden, überwachen Sie Fehlerraten und Logs für 72 Stunden mit erhöhter Aufmerksamkeit und behalten Sie die verschärften Firewall-Regeln bei. Falls die Seite von Google Safe Browsing markiert wurde, beantragen Sie eine Überprüfung über die Search Console – die Entlistung dauert nach der Bereinigung meist Stunden bis einige Tage.

Rechtliche Benachrichtigung — die 72-Stunden-Regel

Gemäß DSGVO Artikel 33 muss eine Verletzung des Schutzes personenbezogener Daten der Aufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden gemeldet werden, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte natürlicher Personen. Artikel 34 verlangt zusätzlich die Benachrichtigung der Betroffenen, wenn das Risiko hoch ist (z. B. geleakte Passwörter oder Zahlungsdaten). Praxis-Punkte:

• Die Uhr beginnt bei Bekanntwerden, nicht bei vollständigem Verständnis. Ein Teilbericht („wir haben unautorisierten Zugriff bestätigt, Umfang in Untersuchung“) innerhalb von 72 Stunden ist konform; Schweigen nicht.
• Dokumentieren Sie die Bewertung auch, wenn Sie entscheiden, nicht zu benachrichtigen – die Begründung ist selbst vorgeschrieben.
• Unternehmen unter der NIS2-Richtlinie haben einen schnelleren Weg: Frühwarnung an das CSIRT innerhalb von 24 Stunden, Vorfallmeldung innerhalb von 72 Stunden.

Kommunikation

Eine Stimme: der IC oder der benannte PR-Verantwortliche. Intern: kurze, sachliche Updates in festem Rhythmus (auch „keine Änderung“). Extern: Ehrlichkeit siegt – sagen Sie, was passiert ist, welche Daten betroffen waren, was Benutzer tun sollten (Passwort-Reset) und was Sie geändert haben. Unternehmen werden selten dafür bestraft, dass sie einen Vorfall hatten; sie werden dafür bestraft, dass sie ihn verheimlichen.

Phase 6 — Nachbereitung

Führen Sie innerhalb von zwei Wochen ein schuldfreies Post-Mortem durch (eine Stunde, der IC moderiert): Zeitstrahl, Ursache, was funktionierte, was war langsam, und 3–5 konkrete Maßnahmen mit Verantwortlichen und Fristen – z. B. „Auto-Updates für Plugins aktivieren“, „Backups auf unveränderlichen Speicher verschieben“, „File-Integrity-Monitoring hinzufügen“. Fügen Sie die Aktionen dem Arbeitsrückstand hinzu; eine nicht zugewiesene Lektion ist eine nicht gelernte Lektion.

Planen Sie abschließend zweimal jährlich eine Tabletop-Übung: Wählen Sie ein Szenario (ein Defacement, das am Freitag um 17:30 Uhr entdeckt wird, ist ein Klassiker), gehen Sie das Playbook mündlich mit dem Team durch und notieren Sie jeden Punkt, an dem jemand sagt: „Hmm, ich bin mir nicht sicher, wer…“. Diese Pausen sind Fehler im Plan – beheben Sie diese auf dem Papier, bevor ein Angreifer sie in Produktion findet.

Arbeitsbeispiel — das Freitagabend-Defacement

Theorie bleibt mit einem Zeitstrahl besser im Gedächtnis. So läuft das Playbook für das häufigste KMU-Szenario: Ein Kunde mailt am Freitag um 17:42, dass die Startseite „seltsam aussieht“.

• 17:45 — Erkennung. Der diensthabende IT-Manager (IC) öffnet die Seite per Smartphone: Die Startseite zeigt ein Banner des Angreifers. Screenshot erstellt. #incident-20260828-Kanal erstellt; SEV-1 erklärt (bestätigte Kompromittierung); CEO gemäß Tabelle informiert.
• 17:55 — Beweise. Vor jeder Aktion: Access- und Error-Logs der letzten 14 Tage vom Server auf lokalen Speicher kopiert; CMS-Audit-Log exportiert; Disk-Snapshot beim Hosting-Anbieter ausgelöst.
• 18:05 — Eindämmung. Site via CDN in den Wartungsmodus geschaltet. Kunden sehen eine neutrale „Bald zurück“-Seite. Alle CMS-Admin-Passwörter von einem bekannten, sauberen Laptop rotiert; MFA erzwungen; der unbekannte Admin-Account in der Benutzerliste deaktiviert, nicht gelöscht (Beweis).
• 18:40 — Analyse. Das CMS-Audit-Log zeigt: Der Rogue-Admin wurde am Dienstag um 03:14 über ein anfälliges Galerie-Plugin (drei Versionen veraltet) erstellt. Datenbanktabellen für Kunden scheinen laut Query-Logs unberührt – notiert, mit Begründung, im Kanal für die DSGVO-Bewertung.
• 19:30 — Beseitigung. Neuer Server aus dem Image des Hosters bereitgestellt; neuestes sauberes Backup (Montag) eingespielt; CMS-Kern und alle Plugins aktualisiert; Galerie-Plugin gelöscht; alle Secrets rotiert.
• 21:10 — Wiederherstellung. DNS/CDN auf den neuen Ursprung gerichtet. Externer Scan bestätigt saubere Inhalte und Header. Wartungsmodus beendet. Erhöhte Log-Überwachung für das Wochenende vereinbart, aufgeteilt zwischen IC und Stellvertreter.
• Montag — Benachrichtigung & Lernen. DSGVO-Bewertung abgeschlossen: keine personenbezogenen Daten abgerufen, dokumentiert, kein Bericht nach Art. 33 erforderlich. Post-Mortem am Mittwoch ergibt drei Aktionen: Auto-Updates an, Plugin-Inventur vierteljährlich, File-Integrity-Monitoring installiert.

Gesamte für Kunden sichtbare Ausfallzeit: etwa drei Stunden, an einem Freitagabend, mit zwei Personen. Dieses Ergebnis ist fast vollständig in Phase 1 erkauft – Snapshot-Fähigkeit, CDN-Wartungsschalter, getestetes Backup und Schweregradtabelle wurden vor 17:42 entschieden.

Zusammenarbeit mit externen Partnern

Drei Beziehungen bestimmen, wie viel Hilfe Sie unter Druck bekommen:

• Hosting-Anbieter. Wissen Sie im Voraus, was diese im Notfall tun können: Snapshots auf Abruf? Netzwerkisolation? Aufbewahrungsdauer für Logs? Die Notfallreaktion ist durch den bezahlten Support oft schneller – entscheiden Sie vor dem Vorfall, ob sich dieser Tarif lohnt (meist ja).
• Forensik / IR-Firma. Bei SEV-1 mit vermutetem Datendiebstahl, Ransomware oder rechtlichem Risiko ziehen Sie frühzeitig Profis hinzu – Fehler bei der Beweisaufnahme in den ersten Stunden sind irreversibel. Eine benannte Firma mit kleinem Retainer antwortet in Stunden; ein Kaltanruf während einer Ransomware-Welle vielleicht erst in Wochen.
• Cyber-Versicherung. Lesen Sie die Police jetzt: Die meisten verlangen Meldung innerhalb eines festen Fensters, manche erfordern die Nutzung eines vom Versicherer zugelassenen IR-Panels – die eigene Firma zu beauftragen, kann den Schutz gefährden. Schreiben Sie beide Fakten auf die Kontaktkarte.

Wenn Erpressung ins Spiel kommt

Wenn der Vorfall mit einer Lösegeldforderung einhergeht – für Entschlüsselung oder Nichtveröffentlichung – halten Sie inne, bevor jemand antwortet. Kommunizieren Sie nicht von privaten oder Firmen-Accounts mit dem Angreifer; ziehen Sie einen Anwalt und bei hohen Forderungen die Polizei hinzu, bevor irgendein Kontakt stattfindet. Zahlen ist in den meisten Jurisdiktionen legal, finanziert aber den nächsten Angriff, bietet keine Garantie und kann sanktioniert sein, wenn die Gruppe auf einer Sanktionsliste steht – ein Check, den Ihr Anwalt oder Versicherer vornehmen muss. Was auch immer beschlossen wird, entscheiden Sie es einmalig, auf Management-Ebene, dokumentiert; der Druck bei Erpressung ist darauf ausgelegt, schnelle Einzelentscheidungen zu erzwingen, und das Playbook soll genau das verhindern.

Erfolgsmessung

Zwei Zahlen, zweimal jährlich überprüft, zeigen, ob sich die Fähigkeiten verbessern:

• MTTD (Mean Time to Detect): Zeit von der Kompromittierung bis zur Kenntnisnahme. Das Defacement-Beispiel oben hatte eine MTTD von drei Tagen – der Angreifer kam Dienstag rein, Sie erfuhren es Freitag. File-Integrity-Monitoring hätte es auf Minuten verkürzt; das ist das Argument für die Post-Mortem-Maßnahme.
• MTTR (Mean Time to Recover): Zeit von der Erkennung bis zur Wiederherstellung. Fast vollständig von der Qualität der Vorbereitung abhängig: getestete Backups, vorab vereinbarte Wartungsschalter und ein benannter Entscheider.

Tabletop-Übungen liefern diese Zahlen sicher: Stoppen Sie den Durchlauf, notieren Sie, wo das Team stockt, und behandeln Sie jedes „das müsste ich nachschlagen“ als Befund.

Vorlage für Kundenbenachrichtigung

Halten Sie einen Entwurf bereit, damit die rechtliche Prüfung die einzige Verzögerung bleibt. Bleiben Sie sachlich, kurz und frei von Adjektiven:

Betreff: Sicherheitsvorfall bezüglich [Dienst] — was passiert ist und was wir tun

Am [Datum] haben wir unautorisierten Zugriff auf [System] festgestellt.
Wir haben den betroffenen Dienst innerhalb von [X Minuten/Stunden]
offline genommen, die Ursache entfernt und den Dienst am [Datum/Zeit]
wiederhergestellt.

Was war betroffen: [spezifische Datenkategorien, oder "keine Kundendaten,
basierend auf unserer Log-Analyse"].

Was Sie tun sollten: [Passwort ändern / keine Aktion erforderlich].

Wir haben den Vorfall an [Behörde] gemeldet und [externe Experten]
beauftragt, unsere Ergebnisse zu verifizieren. Wir werden diese Seite
aktualisieren, sobald die Untersuchung abgeschlossen ist: [Status-URL].

Kontakt: security@yourcompany.com

Checkliste auf einer Seite

• Schweregradtabelle adoptiert; Incident Commander + Stellvertreter benannt
• Kontaktkarte ausgedruckt und im Passwort-Manager gespeichert
• 3-2-1 Backups mit einer offline/unveränderlichen Kopie; Restore-Übung dieses Quartal durchgeführt
• Uptime-, Defacement- und externes Überwachungs-Monitoring alarmiert auf Telefone
• Beweisregel bekannt: Logs zuerst kopieren, isolieren – nicht ausschalten
• Eindämmungsoptionen vorab mit Hosting/CDN-Anbieter abgestimmt
• Neu-aufsetzen-statt-reinigen-Richtlinie bei Server-Kompromittierung
• DSGVO 72h / NIS2 24h Meldepflichten auf die Organisation gemappt
• Vorlage für schuldfreies Post-Mortem bereit; Tabletop-Übung geplant

Quellen

• NIST SP 800-61 — Incident Response Recommendations and Considerations
• ENISA — Incident response and cyber crisis material
• GDPR Article 33 — Notification of a personal data breach
• GDPR Article 34 — Communication to the data subject
• NIS2 Directive (EU) 2022/2555
• IMY — Report a personal data breach (Sweden)
• Google Search Console — Request a security review