WordPress, reakcja na incydent pod NIS2: 24-godzinny playbook wczesnego ostrzeżenia
Artykuł 23 Dyrektywy 2022/2555 ściska wczesny etap reakcji na incydent w trzy terminy: 24 godziny, 72 godziny, miesiąc. Zegar 24-godzinny zaskakuje operatorów WordPress, bo startuje przy powzięciu wiedzy, nie przy naprawie, a powzięcie wiedzy w typowej witrynie WordPress przychodzi raczej z wiadomości na Slacku niż z dashboardu SOC.
To artykuł wspierający w filarze NIS2 i DORA na WordPress, z odsyłaczami do ścieżki dowodowej Załącznika II i audytu dostawcy z artykułu 28 DORA.
TL;DR
- 24 godziny od powzięcia wiedzy: wczesne ostrzeżenie do CSIRT.
- 72 godziny od powzięcia wiedzy: zgłoszenie z oceną wstępną.
- 1 miesiąc od powzięcia wiedzy: raport końcowy z przyczyną i naprawą.
- „Powzięcie wiedzy” to wyzwalacz, nie alert SIEM.
- Sześć sygnałów WordPress, które dla mnie znaczą „zegar idzie”.
- Szablony plików w językach narodowych w tym playbooku.
Co dokładnie mówi artykuł 23
Artykuł 23 ust. 1 ustanawia obowiązek: zgłoszenie każdego incydentu mającego znaczący wpływ na świadczenie usług do CSIRT lub właściwego organu. Artykuł 23 ust. 3 definiuje „znaczący”: mogący spowodować poważne zakłócenie operacyjne usług lub stratę finansową dla podmiotu albo szkody materialne lub niematerialne u innych osób fizycznych lub prawnych.
Artykuł 23 ust. 4 dzieli oś czasu:
- (a) Bez nieuzasadnionej zwłoki, w każdym razie w ciągu 24 godzin od powzięcia wiedzy o znaczącym incydencie: wczesne ostrzeżenie wskazujące, czy incydent jest podejrzewany o przyczynę bezprawną lub złośliwą oraz czy może mieć skutek transgraniczny.
- (b) Bez nieuzasadnionej zwłoki, w każdym razie w ciągu 72 godzin: zgłoszenie aktualizujące wczesne ostrzeżenie i zawierające ocenę wstępną z dotkliwością, wpływem i wskaźnikami kompromitacji.
- (c) Na żądanie CSIRT lub właściwego organu: raport pośredni o stanie.
- (d) Nie później niż miesiąc po zgłoszeniu z lit. b: raport końcowy ze szczegółowym opisem, typem zagrożenia lub przyczyną źródłową, podjętymi działaniami naprawczymi, ewentualnym skutkiem transgranicznym.
Zegar startuje przy powzięciu wiedzy o znaczącym incydencie. Wytyczne ENISA czytają „powzięcie wiedzy” jako moment, w którym fachowa osoba w podmiocie z wystarczającą pewnością uznaje, że doszło do znaczącego incydentu. To istotne dla WordPress, bo powzięcie wiedzy zwykle przychodzi z e-maila klienta, zewnętrznej usługi monitorującej lub skanera podatności, nie z wewnętrznego SOC.
Sześć sygnałów WordPress wymagających natychmiastowej oceny
Te ustalenia wymagają otwarcia rekordu i natychmiastowej oceny znaczenia. Nie uruchamiają automatycznie terminu NIS2. Artykuł 23 ma zastosowanie, gdy objęty regulacją podmiot poweźmie wiedzę, że incydent jest znaczący według właściwych zasad.
1. Defacement na stronie klienckiej. Indeksowane defacementy, podmieniona strona główna, podmienione strony produktów. Widoczność ułatwia ocenę dotkliwości: szkoda dla zaufania klienta jest dana.
2. Kompromitacja konta admina z potwierdzonym logowaniem. Nowe konto admina, istniejące konto admina z logowaniami z nietypowego zakresu IP lub kraju, konto admina zmieniające inne konta. Wykrywane przez wtyczki audit log (WP Activity Log, Stream, Wordfence audit log).
3. Instalacja złośliwej wtyczki lub upload motywu. Plik wtyczki w wp-content/plugins/ poza zwykłym kanałem aktualizacji albo z PHP wywołującym eval, base64_decode, gzinflate czy assert na danych użytkownika. Wykrywane przez monitoring integralności plików lub skan Wordfence.
4. Iniekcja do bazy z potwierdzonym zapisem. SQL injection, który zdołał wstawić lub zmienić wiersze. Potwierdzone diff-em audit log lub manipulacją w wp_users lub wp_options. Klasyczny sygnał: opcja siteurl nagle wskazuje na obcą domenę.
5. Nieuprawniony eksport danych osobowych. Eksport WordPress, wywołanie REST API zwracające listę użytkowników, duża odpowiedź wp-json/wp/v2/users z nieoczekiwanej IP. RODO artykuł 33 może zadziałać równolegle z NIS2 artykułem 23.
6. Ransomware lub szyfrowanie systemu plików na produkcji albo backupach. Pliki z nowymi rozszerzeniami, .html z notą okupu w katalogach upload, zaszyfrowane archiwa kopii. To sygnał wysokiej wagi, ale zakres i znaczenie nadal wymagają udokumentowanej decyzji.
Dla każdego z tych ustaleń runbook agencyjny mówi: oznacz znacznikiem czasu moment powzięcia wiedzy w tickecie IR, nazwij osobę odpowiedzialną, wystartuj zegar 24-godzinny, powiadom CISO podmiotu lub jego odpowiednik w pierwszej godzinie. Agencja nie składa do CSIRT; podmiot składa. Agencja dostarcza treść techniczną.
Szablon wczesnego ostrzeżenia (24-godziny)
Wczesne ostrzeżenie jest celowo krótkie. Szablon, który składam zespołowi compliance podmiotu:
Podmiot: [nazwa prawna]
Sektor: [klasyfikacja Załącznika I lub II]
Identyfikator krajowy: [NIP lub numer rejestrowy]
Streszczenie incydentu
Data i czas powzięcia wiedzy: [ISO-8601 ze strefą czasową]
Źródło wykrycia: [audit log / zgłoszenie klienta / zewnętrzny skaner / powiadomienie hostera]
Dotknięta usługa: [publiczna witryna WordPress pod https://example.com, portal klienta itd.]
Klasyfikacja wstępna
Domniemana przyczyna: [złośliwa / przypadkowa / w toku]
Skutek transgraniczny: [tak / nie / w toku]
Wskaźniki skutku transgranicznego: [jeśli tak, co na to wskazuje]
Wstępna ocena wpływu
Dostępność usługi: [działa / pogorszona / niedostępna]
Potwierdzony dostęp do danych: [brak / podejrzenie / potwierdzony]
Liczba potencjalnie dotkniętych osób: [liczba jeśli znana, w przeciwnym razie „w toku"]
Pierwsza reakcja
Działania powstrzymujące: [rotacja poświadczeń, usunięcie wtyczki, blokada IP itd.]
Forensyka w toku: [tak / nie, z nazwą dostawcy jeśli zewnętrzny]
Następne uaktualnienie: [czas zgłoszenia 72-godzinnego lub wcześniejszego raportu pośredniego]
Kontakt
Imię i rola: [CISO, szef IT itd.]
E-mail i telefon: [linia bezpośrednia]To wczesne ostrzeżenie, nie zgłoszenie. Zgłoszenie 72-godzinne rozszerza je o ocenę dotkliwości, wskaźniki kompromitacji i jaśniejszą ocenę transgraniczną.
Zgłoszenie 72-godzinne: co dochodzi
W ciągu 72 godzin od powzięcia wiedzy zgłoszenie dodaje:
- Ocenę dotkliwości. Liczbę dotkniętych użytkowników, rozkład geograficzny, oszacowanie straty finansowej, szacowany czas odzyskania.
- Wskaźniki kompromitacji. Adresy IP, hashe plików, URL-e, złośliwe ciągi User-Agent, sygnatury ataku. ENISA rekomenduje schemat; CSIRT-y akceptują STIX 2.1 lub listę dowolną.
- Ocenę skutku transgranicznego. Potwierdzony lub wykluczony, z uzasadnieniem.
- Stan powstrzymywania. Co jest opanowane, co otwarte.
- Potrzeby współpracy. Czy podmiot potrzebuje wsparcia CSIRT lub innych organów.
W WordPress blok wskaźników zwykle zawiera: IP atakujących z access logów, ścieżki złośliwych plików w wp-content/, hashe złośliwych plików, ciągi User-Agent obserwowane w trakcie eksploitacji oraz HTTP request body zachowane przez WAF.
Raport końcowy w ciągu miesiąca
Artykuł 23 ust. 4 lit. d: raport końcowy nie później niż miesiąc po zgłoszeniu. Treść:
- Szczegółowy opis incydentu.
- Typ zagrożenia lub przyczyna źródłowa.
- Podjęte i trwające działania naprawcze.
- Skutek transgraniczny w stosownym zakresie.
Dla incydentów WordPress sekcja przyczyny zwykle ląduje na jednym z: nieaktualna wtyczka z znanym CVE, słabe poświadczenia admina bez MFA, wystawiony wp-config.php z pliku backupu, RCE przez funkcję motywu, kompromitacja łańcucha dostaw kanału aktualizacji, błędna konfiguracja na serwerze. Sekcja działań naprawczych mapuje przyczynę na środek z artykułu 21 ust. 2, który powinien był temu zapobiec, i aktualizuje rejestr ryzyka podmiotu.
Gdzie składać: krajowe CSIRT-y
Każde państwo członkowskie wyznacza co najmniej jeden CSIRT i jeden właściwy organ. Aktualną listę prowadzi portal ENISA. Najczęstsze kierunki dla podmiotów, z którymi pracuję:
- Polska. CSIRT NASK dla sektorów cywilnych, CSIRT GOV dla administracji publicznej, CSIRT MON dla obszaru obronnego. Krajowy organ właściwy zależy od sektora.
- Niemcy. Bundesamt für Sicherheit in der Informationstechnik (BSI) i CERT-Bund. Sektorowe CSIRT-y dla finansów (CSIRT BaFin), energii i telekomunikacji.
- Hiszpania. INCIBE-CERT dla sektora prywatnego i obywateli, CCN-CERT dla administracji publicznej.
- Norwegia. Nie jest członkiem UE, lecz aligned w ramach EOG; NSM NCSC przyjmuje zgłoszenia sektorów dobrowolnie zharmonizowanych.
- Portugalia. CERT.PT pod CNCS (Centro Nacional de Cibersegurança).
Dla podmiotów działających w wielu jurysdykcjach ENISA prowadzi listę pojedynczych punktów kontaktowych (SPOC) do koordynacji transgranicznej.
Przygotowanie, które umożliwia 24 godziny
Termin 24-godzinny jest bezlitosny dla podmiotów, które przygotowują się dopiero po powzięciu wiedzy. Przed jakimkolwiek incydentem:
- Imienna rotacja on-call. Dwie osoby, główna i zastępcza, z numerami w runbooku IR.
- Drzewo eskalacji do CISO podmiotu. Agencja nie składa wczesnego ostrzeżenia; robi to podmiot, więc droga od „agencja widzi” do „podmiot decyduje” musi być pod godzinę.
- Szablony komunikacji przygotowane wcześniej. Notyfikacja klienta, notyfikacja wewnętrzna, notyfikacja regulatora. Wszystkie trzy w odpowiednich językach.
- Możliwość snapshotu produkcyjnej instancji WordPress. Przed jakąkolwiek zmianą powstrzymującą zachowaj system plików i bazę dla forensyki.
- Relacja z dostawcą forensyki, zakontraktowana zawczasu. Forensyka pod artykułem 23 w 72 godziny wymaga dostawcy, który odbiera telefon, nie zapytania ofertowego.
- Off-site backup w trybie immutable. Bez niego ransomware może uniemożliwić raport końcowy, niszcząc dowody.
Wycena przygotowania tej gotowości jest indywidualna i zależy od skali parku WordPress; nie jest to pozycja na fakturze hostingowej.
Triage operacyjny, dowody i decyzje
Po wiarygodnym sygnale zespół otwiera jeden główny rekord incydentu. Zapisuje pierwotną obserwację, czas ze strefą, źródło, środowisko i osobę prowadzącą. Ocenia autentyczność, wpływ na poufność, integralność i dostępność, a dopiero potem możliwe spełnienie kryteriów znaczącego incydentu. Poziomy operacyjne, takie jak zdarzenie, poważny incydent i kryzys, porządkują zasoby, ale nie zastępują artykułu 23 ani prawa krajowego. Potwierdzony dostęp, konta, komponenty, ścieżki klientów, czas, zasięg, dostawcy i poziom pewności są aktualizowane. Niewiadome pozostają oznaczone.
Powstrzymywanie i zabezpieczenie dowodów biegną równolegle. Przed przebudową lub usunięciem podejrzanego kodu, jeśli jest to bezpieczne, zapisuje się snapshot lub kopię plików, stan bazy, identyfikator wdrożenia, sesje, administratorów i logi. Oryginały zostają zachowane, pliki otrzymują sumy kontrolne, a kopie robocze są oddzielone. Każda zmiana, w tym rotacja danych dostępowych, reguła WAF, usunięcie wtyczki, odtworzenie i DNS, trafia do osi czasu. Bezpieczeństwo ma pierwszeństwo, gdy zachowanie dowodu przedłuża szkodę; brak trzeba uzasadnić.
Obok osi technicznej działa chronologiczny dziennik decyzji z faktami, założeniami, alternatywami, właścicielem i terminem przeglądu. Technika, zarząd, prawo i prywatność oraz komunikacja do klientów mają oddzielne strumienie uzgadniane przez koordynatora. Agencja przekazuje komponenty, czas wykrycia, referencje do dowodów, stan powstrzymania, podejrzewany dostęp i szacunek odtworzenia. Podmiot podejmuje decyzję i zgłasza, chyba że wyraźna autoryzacja stanowi inaczej.
Próba, akceptacja i dowody po incydencie
Ćwiczenie powinno połączyć hostera, agencję, lidera incydentu, prywatność i komunikację. Przechodzi od alertu przez dowody i ocenę znaczenia do przekazania regulatorowi, zgody na odtworzenie i wiadomości dla klientów. Akceptacja wymaga reakcji dyżuru, prawidłowego rekordu, zebrania dowodów bez improwizowanego dostępu, przekazania do decydenta, aktualnych szablonów, czystego punktu odtworzenia oraz właściciela i terminu dla każdej poprawy.
Po odtworzeniu zostają oś czasu, dziennik decyzji, indeks dowodów, kopie zgłoszeń, lista aktywów, analiza przyczyny, dowód restore, komunikacja i weryfikacja napraw. Tymczasowe zabezpieczenie zastępuje trwała kontrola albo formalna decyzja o ryzyku rezydualnym.
W celu przygotowania lub próby wyślij pisemny opis przez usługę gotowości NIS2 i DORA. Podaj podmiot, jurysdykcje, środowiska WordPress, hosting, kluczowe ścieżki, logowanie, backupy, kontakty, wcześniejsze ćwiczenia i luki. Nie przesyłaj początkowo danych dostępowych, osobowych ani surowych dowodów kompromitacji. Praca poprawia gotowość i dowody, ale nie jest opinią prawną, gwarancją ani automatycznym stwierdzeniem obowiązku zgłoszenia.
Powiązane teksty o zgodności
- Filar: NIS2 i DORA na WordPress: stos zgodności 2026
- NIS2 Załącznik II dla agencji WordPress: zakres, terminy, ścieżka dowodowa
- DORA artykuł 28 ryzyko stron trzecich ICT: audyt dostawcy hostingu i WAF dla WordPress
- Cyber Resilience Act + NIS2 + DORA: stos zgodności 2026 dla headless WordPress
- NIS2 zgłoszenie incydentu WordPress: 24 godziny, 72 godziny, miesiąc
- NIS2 vs DORA pokrywanie się zakresów dla agencji WordPress 2026
- Audyt zgodności EU dla WordPress
