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, które uruchamiają zegar
Następujące sześć ustaleń traktuję jako wyzwalacze powzięcia wiedzy. Każde z nich domyślnie startuje 24-godzinny zegar, z opcją wycofania, jeśli triage wstępny wyklucza znaczność.
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. Znaczność jest automatyczna.
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.
