WordPress-Vorfallsreaktion unter NIS2: 24-Stunden-Frühwarnungs-Playbook
Artikel 23 der Richtlinie 2022/2555 presst die Anfangsphase der Vorfallsreaktion in drei Fristen: 24 Stunden, 72 Stunden, ein Monat. Der 24-Stunden-Zähler trifft WordPress-Betreiber unvorbereitet, weil er bei Kenntnisnahme startet, nicht bei der Behebung, und Kenntnisnahme auf einer typischen WordPress-Site eher aus einer Slack-Nachricht als aus einem SOC-Dashboard kommt.
Dies ist ein vertiefender Beitrag im Pillar zu NIS2 und DORA auf WordPress mit Querverweisen auf den Anhang-II-Nachweispfad und das DORA-Artikel-28-Lieferanten-Audit.
TL;DR
- 24 Stunden ab Kenntnisnahme: Frühwarnung an das CSIRT.
- 72 Stunden ab Kenntnisnahme: Vorfallsmeldung mit Erstbewertung.
- 1 Monat ab Kenntnisnahme: Abschlussbericht mit Ursache und Gegenmaßnahmen.
- „Kenntnisnahme” ist der Auslöser, nicht ein SIEM-Alert.
- Sechs WordPress-Signale, die für mich „der Zähler läuft jetzt” bedeuten.
- Vorlagen je Sprache stehen in diesem Playbook.
Was Artikel 23 tatsächlich sagt
Artikel 23 Absatz 1 setzt die Pflicht: Meldung jedes Vorfalls mit erheblichen Auswirkungen auf die Bereitstellung der Dienste an das CSIRT oder die zuständige Behörde. Artikel 23 Absatz 3 definiert „wesentlich”: geeignet, schwere Betriebsstörung der Dienste oder finanziellen Schaden für die Einrichtung zu verursachen, oder geeignet, andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden zu beeinträchtigen.
Artikel 23 Absatz 4 splittet die Zeitachse:
- (a) Unverzüglich, in jedem Fall innerhalb von 24 Stunden ab Kenntnisnahme des wesentlichen Vorfalls: eine Frühwarnung mit Angabe, ob der Vorfall vermutlich auf rechtswidrige oder böswillige Handlungen zurückzuführen ist und ob er grenzüberschreitende Auswirkungen haben könnte.
- (b) Unverzüglich, in jedem Fall innerhalb von 72 Stunden: eine Vorfallsmeldung, die die Frühwarnung aktualisiert und eine Erstbewertung mit Schweregrad, Auswirkung und Indikatoren einer Kompromittierung enthält.
- (c) Auf Anforderung des CSIRT oder der zuständigen Behörde: Zwischenbericht zum Stand.
- (d) Spätestens einen Monat nach der Vorfallsmeldung nach Buchstabe b: Abschlussbericht mit detaillierter Beschreibung, Bedrohungstyp oder Ursache, umgesetzten Gegenmaßnahmen, gegebenenfalls grenzüberschreitenden Auswirkungen.
Der Zähler startet bei der Kenntnisnahme des wesentlichen Vorfalls. ENISA-Leitlinien lesen „Kenntnisnahme” als den Moment, in dem eine fachkundige Person in der Einrichtung mit hinreichender Sicherheit einschätzt, dass ein wesentlicher Vorfall vorliegt. Für WordPress entscheidend, weil Kenntnisnahme meist aus einer Kunden-E-Mail, einem externen Monitoring-Dienst oder einem Schwachstellen-Scanner kommt, nicht aus einem internen SOC.
Sechs WordPress-Signale für die sofortige Triage
Diese Befunde verlangen einen Vorfallsdatensatz und eine sofortige Wesentlichkeitsprüfung. Sie starten nicht automatisch eine NIS2-Frist. Artikel 23 greift, wenn eine erfasste Einrichtung Kenntnis davon erlangt, dass ein Vorfall nach den anwendbaren Regeln erheblich ist.
1. Defacement auf einer kundenseitigen Seite. Suchmaschinenindexierte Defacements, ersetzte Startseite, ersetzte Produktseiten. Die Sichtbarkeit macht die Schwere-Bewertung leicht: Vertrauensschaden ist gegeben.
2. Kompromittierter Admin mit bestätigter Anmeldung. Ein neuer Admin-Account, ein bestehender Admin-Account mit Anmeldungen aus ungewöhnlichem IP-Bereich oder Land, ein Admin-Account, der andere Konten ändert. Festgestellt von Audit-Log-Plugins (WP Activity Log, Stream, Wordfence-Audit-Log).
3. Böswillige Plugin-Installation oder Theme-Upload. Eine Plugin-Datei in wp-content/plugins/ außerhalb des regulären Updatekanals oder mit PHP, das eval, base64_decode, gzinflate oder assert auf Eingabedaten ausführt. Erkannt durch Datei-Integritätsüberwachung oder Wordfence-Scan.
4. Datenbank-Injection mit bestätigtem Schreibvorgang. SQL-Injection, der Zeilen einfügen oder ändern konnte. Bestätigt durch Audit-Log-Diff oder durch Manipulation an wp_users oder wp_options. Klassisches Signal: die siteurl-Option zeigt plötzlich auf eine fremde Domain.
5. Unberechtigter Personendaten-Export. WordPress-Export, REST-API-Aufruf mit Benutzerlisten, große wp-json/wp/v2/users-Antwort von einer unerwarteten IP. DSGVO-Artikel 33 kann zusätzlich zu NIS2 Artikel 23 greifen.
6. Ransomware oder Dateisystem-Verschlüsselung auf Produktionsserver oder Backups. Dateien mit neuen Endungen, .html-Lösegeldforderungen in Upload-Verzeichnissen, verschlüsselte Backup-Archive. Das ist ein Signal hoher Schwere, Umfang und Wesentlichkeit brauchen dennoch eine dokumentierte Entscheidung.
Für jeden dieser Befunde sagt das Agentur-Runbook: Zeitstempel der Kenntnisnahme im IR-Ticket, benannte verantwortliche Person, 24-Stunden-Zähler starten, CISO oder Pendant der Einrichtung in der ersten Stunde benachrichtigen. Die Agentur reicht nicht beim CSIRT ein; die Einrichtung tut es. Die Agentur liefert den technischen Inhalt.
Vorlage Frühwarnung (24-Stunden)
Die Frühwarnung ist bewusst kurz. Vorlage, die ich beim Konformitäts-Team der Einrichtung einreiche:
Einrichtung: [rechtlicher Name]
Sektor: [Anhang I oder II Klassifizierung]
Nationale Kennung: [Steuer-ID oder Registernummer]
Vorfallszusammenfassung
Datum und Uhrzeit der Kenntnisnahme: [ISO-8601 mit Zeitzone]
Erkennungsquelle: [Audit-Log / Kundenmeldung / externer Scanner / Hosting-Anbieter]
Betroffener Dienst: [öffentliche WordPress-Site unter https://example.com, Kundenportal etc.]
Erstklassifizierung
Vermutete Ursache: [böswillig / versehentlich / in Untersuchung]
Grenzüberschreitende Auswirkung: [ja / nein / in Untersuchung]
Indikatoren grenzüberschreitender Wirkung: [falls ja, was deutet darauf hin]
Erstauswirkung
Verfügbarkeit: [erreichbar / eingeschränkt / nicht erreichbar]
Bestätigter Datenzugriff: [keiner / vermutet / bestätigt]
Potenziell betroffene Betroffene: [Anzahl falls bekannt, sonst „in Untersuchung"]
Erstmaßnahmen
Eindämmungsmaßnahmen: [Zugangsdaten rotiert, Plugin entfernt, IP gesperrt etc.]
Forensik läuft: [ja / nein, mit Anbieter falls extern]
Nächstes Update: [Zeitpunkt der 72-Stunden-Meldung oder früherer Zwischenbericht]
Kontakt
Name und Rolle: [CISO, IT-Leitung etc.]
Kontakt-E-Mail und Telefon: [Direktnummer]Das ist die Frühwarnung, nicht die Vorfallsmeldung. Die 72-Stunden-Meldung erweitert sie um Schwere-Bewertung, Indikatoren der Kompromittierung und eine klarere grenzüberschreitende Einschätzung.
72-Stunden-Meldung: was ergänzt wird
Innerhalb von 72 Stunden ab Kenntnisnahme ergänzt die Meldung:
- Schwere-Bewertung. Anzahl betroffener Nutzer, geografische Verteilung, Schätzung des finanziellen Schadens, geschätzte Wiederherstellungszeit.
- Indikatoren der Kompromittierung. IP-Adressen, Datei-Hashes, URLs, böswillige User-Agent-Strings, Angriffssignaturen. ENISA empfiehlt ein Schema; CSIRTs akzeptieren STIX 2.1 oder eine Freitextliste.
- Grenzüberschreitende Auswirkungsbewertung. Bestätigt oder ausgeschlossen, mit Begründung.
- Stand der Eindämmung. Was eingedämmt ist, was offen.
- Kooperationsbedarf. Ob die Einrichtung Unterstützung von CSIRT oder anderen Behörden benötigt.
Für WordPress enthält der Indikatoren-Block in der Regel: Angreifer-IPs aus den Access-Logs, böswillige Dateipfade in wp-content/, Hashes böswilliger Dateien, beobachtete User-Agent-Strings und alle vom WAF erhaltenen HTTP-Request-Bodies.
Abschlussbericht binnen eines Monats
Artikel 23 Absatz 4 Buchstabe d: Abschlussbericht spätestens einen Monat nach der Vorfallsmeldung. Inhalte:
- Detaillierte Beschreibung des Vorfalls.
- Bedrohungstyp oder Ursache.
- Umgesetzte und laufende Gegenmaßnahmen.
- Grenzüberschreitende Auswirkung, sofern zutreffend.
Bei WordPress-Vorfällen landet die Ursachenbeschreibung typischerweise auf einem von: veraltetem Plugin mit bekanntem CVE, schwachem Admin-Passwort ohne MFA, ausgesetzter wp-config.php aus einer Backup-Datei, RCE über eine Theme-Funktion, Lieferketten-Kompromittierung eines Updatekanals, server-seitiger Fehlkonfiguration. Der Maßnahmen-Teil bildet die Ursache auf die Maßnahme aus Artikel 21 Absatz 2 ab, die das verhindert hätte, und aktualisiert das Risikoregister der Einrichtung.
Wo einreichen: nationale CSIRTs
Jeder Mitgliedstaat benennt ein oder mehrere CSIRTs und eine zuständige Behörde. Die aktuelle Liste pflegt das ENISA-Portal. Häufige Anlaufstellen für Einrichtungen, mit denen ich arbeite:
- Deutschland. Bundesamt für Sicherheit in der Informationstechnik (BSI) und CERT-Bund. Sektor-CSIRTs für Finanzen (CSIRT BaFin), Energie und Telekommunikation.
- Polen. CSIRT NASK für zivile Sektoren, CSIRT GOV für die öffentliche Verwaltung, CSIRT MON für verteidigungsnahe Bereiche.
- Spanien. INCIBE-CERT für Privatsektor und Bürger, CCN-CERT für die öffentliche Verwaltung.
- Norwegen. Kein EU-Mitglied, jedoch EWR-aligned; NSM NCSC nimmt Meldungen freiwillig orientierter Sektoren entgegen.
- Portugal. CERT.PT unter dem CNCS (Centro Nacional de Cibersegurança).
Für Einrichtungen mit mehreren Jurisdiktionen pflegt ENISA die Single-Point-of-Contact-Liste (SPOC) für die grenzüberschreitende Koordination.
Vorbereitung, die die 24 Stunden ermöglicht
Die 24-Stunden-Frist ist gnadenlos für Einrichtungen, die mit der Vorbereitung erst bei Kenntnisnahme beginnen. Vor jedem Vorfall:
- Eine benannte On-Call-Rotation. Zwei Personen, primär und sekundär, mit Telefonnummern im IR-Runbook.
- Ein Eskalationsbaum zum CISO der Einrichtung. Die Agentur kann die Frühwarnung nicht einreichen; die Einrichtung muss, also muss der Pfad von „Agentur sieht etwas” zu „Einrichtung entscheidet” unter einer Stunde liegen.
- Vorlagen für die Kommunikation. Kundenbenachrichtigung, interne Benachrichtigung, Behördenmeldung. Alle drei in allen relevanten Sprachen.
- Snapshot-Fähigkeit für die Produktions-WordPress-Instanz. Vor jeder Eindämmungsänderung Dateisystem und Datenbank für die Forensik sichern.
- Eine Beziehung zu einem Forensik-Anbieter, vorab vertraglich geregelt. Forensik nach Artikel 23 binnen 72 Stunden braucht einen Anbieter, der ans Telefon geht, keine Beschaffungsausschreibung.
- Ein Off-Site-immutables Backup. Ohne dieses kann Ransomware den Abschlussbericht verhindern, indem sie Beweise zerstört.
Die Preisgestaltung für die Einrichtung dieser Bereitschaft ist individuell und hängt vom Umfang der WordPress-Landschaft ab; sie ist keine Position auf einer Hosting-Rechnung.
Operative Triage, Beweise und Entscheidungen
Bei einem glaubwürdigen Signal wird ein zentraler Vorfallsdatensatz geöffnet. Darin stehen die unveränderte Erstbeobachtung, Zeit mit Zeitzone, Quelle, Umgebung und Triage-Leitung. Geprüft werden Echtheit, Wirkung auf Vertraulichkeit, Integrität und Verfügbarkeit und erst danach eine mögliche Erheblichkeit. Operative Stufen wie Ereignis, schwerer Vorfall und Krise steuern Ressourcen, ersetzen aber weder Artikel 23 noch nationales Recht. Bestätigte Zugriffe, Konten, Komponenten, Kundenwege, Dauer, geografischer Umfang, Lieferantenbezug und Sicherheitsgrad werden fortlaufend aktualisiert. Unbekanntes bleibt als solches markiert.
Eindämmung und Beweissicherung laufen parallel. Vor Neuinstallation oder Löschung verdächtigen Codes werden, soweit sicher, Snapshot oder Dateikopie, Datenbankzustand, Deployment-Kennung, Sitzungen, Administratorliste und Protokolle gesichert. Originalexporte bleiben erhalten, übertragene Forensikdateien erhalten Hashwerte, Arbeitskopien bleiben getrennt. Jede Zustandsänderung wie Passwortrotation, WAF-Regel, Plugin-Entfernung, Restore und DNS-Änderung kommt in die Zeitleiste. Wenn Beweissicherung laufenden Schaden verlängern würde, hat Sicherheit Vorrang; die Lücke wird begründet.
Neben der technischen Zeitleiste steht ein chronologisches Entscheidungsprotokoll. Jeder Eintrag nennt Entscheidung, Tatsachen, Annahmen, Alternativen, Eigentümer und nächsten Prüfpunkt. Technik, Management, Recht und Datenschutz sowie Kundenkommunikation erhalten getrennte Informationsstränge, die eine Koordination abgleicht. Die Agentur liefert Komponenten, Entdeckungszeit, Beweisreferenzen, Eindämmungsstand, vermuteten Zugriff und Recovery-Schätzung. Die Einrichtung entscheidet und meldet, sofern keine ausdrücklich autorisierte Regelung anderes festlegt.
Übung, Abnahme und Nachweise danach
Eine Übung verbindet Host, Agentur, Vorfallsleitung, Datenschutz und Kommunikation. Sie reicht vom Alert über Beweissicherung und Wesentlichkeitsprüfung bis zu Behördenübergabe, Recovery-Freigabe und Kundeninformation. Das Playbook ist abgenommen, wenn Bereitschaft reagiert, der richtige Datensatz öffnet, Beweise ohne improvisierten Zugang erfasst werden, Entscheider die Übergabe erhalten, Vorlagen aktuell sind, ein sauberer Wiederherstellungspunkt freigegeben werden kann und jede Maßnahme Eigentümer und Termin erhält.
Nach der Wiederherstellung bleiben Zeitleiste, Entscheidungsprotokoll, Beweisindex, Meldungskopien, Asset-Liste, Ursachenanalyse, Restore-Nachweis, Kommunikation und Verifikation der Reparaturen erhalten. Vorläufige Eindämmung wird durch eine dauerhafte Kontrolle oder eine ausdrückliche Restrisikoentscheidung ersetzt.
Für Vorbereitung oder Übung senden Sie eine schriftliche Kurzbeschreibung über den NIS2- und DORA-Readiness-Service. Nennen Sie Rechtsträger, Jurisdiktionen, WordPress-Umgebungen, Hosting, wesentliche Kundenwege, Logging, Backups, Vorfallskontakte, frühere Übungen und Prüflücken. Zugangsdaten, personenbezogene Daten und rohe Kompromittierungsbeweise gehören nicht in die erste Nachricht. Die Arbeit verbessert Bereitschaft und Nachweise, ist aber weder Rechtsgutachten noch Garantie oder automatische Feststellung einer Meldepflicht.
Cluster-Lektüre
- Pillar: NIS2 und DORA auf WordPress: Konformitäts-Stack 2026
- NIS2 Anhang II für WordPress-Agenturen: Geltungsbereich, Fristen, Nachweispfad
- DORA Artikel 28 IKT-Drittparteirisiko: WordPress-Hosting- und WAF-Lieferanten-Audit
- Cyber Resilience Act + NIS2 + DORA: 2026 compliance stack for headless WordPress (EN)
- NIS2 Incident-Meldepflicht WordPress: 24 Stunden, 72 Stunden, ein Monat
- NIS2 vs DORA Geltungsbereich-Überschneidung für WordPress-Agenturen 2026
- EU-Konformitätsaudit für WordPress
