Monitoring integralności stron WWW a DORA, NIS2 i KSC. Jak wykrywać nieautoryzowane zmiany?

Strona internetowa może działać bez zakłóceń, odpowiadać kodem HTTP 200 i przechodzić testy dostępności, a jednocześnie wyświetlać treści zmodyfikowane przez cyberprzestępców. Podmieniony formularz, złośliwy kod JavaScript przechwytujący dane czy link prowadzący do witryny phishingowej mogą pozostać niewidoczne dla tradycyjnego monitoringu dostępności.

Tymczasem DORA, NIS2 i polska ustawa o krajowym systemie cyberbezpieczeństwa (KSC) nakładają na określone organizacje obowiązki dotyczące zarządzania ryzykiem, wykrywania zagrożeń i reagowania na incydenty. Czy zewnętrzny monitoring integralności stron WWW może wspierać realizację tych wymagań? Jakie anomalie można wykrywać i kiedy nieautoryzowana zmiana strony powinna uruchomić procedury bezpieczeństwa?

Nieautoryzowana modyfikacja witryny może być nie tylko problemem wizerunkowym, lecz także sygnałem kompromitacji systemu, zagrożenia dla danych użytkowników lub naruszenia bezpieczeństwa usług. Dlatego organizacje powinny obserwować nie tylko dostępność swoich serwisów, ale również zmiany zachodzące w ich publicznej warstwie.

Dlaczego strona WWW może być niebezpieczna, mimo że działa poprawnie?

Systemy monitorowania dostępności sprawdzają między innymi czas odpowiedzi, status HTTP, ważność certyfikatu TLS oraz działanie wybranych funkcji. Jeżeli testy zakończą się powodzeniem, administrator może otrzymać informację, że serwis działa prawidłowo.

Nie jest to jednak potwierdzenie jego bezpieczeństwa.

Atakujący może wykorzystać podatność systemu CMS, przejąć konto administratora lub uzyskać dostęp do serwisu inną metodą. Następnie może zmodyfikować zawartość witryny, dodać złośliwy kod albo podmienić elementy interfejsu. Serwer nadal będzie dostępny, a podstawowy monitoring uptime niekoniecznie wykryje takie zmiany.

Monitoring dostępności odpowiada przede wszystkim na pytanie, czy serwis działa. Monitoring integralności WWW pozwala natomiast obserwować, czy jego zawartość, wygląd lub wybrane elementy kodu nie zmieniły się w nieoczekiwany sposób.

Do zagrożeń należą między innymi:

• defacement, czyli nieautoryzowana zmiana wyglądu lub treści strony;
• podmiana formularzy logowania i płatności;
• wstrzyknięcie złośliwego kodu JavaScript;
• umieszczenie linków prowadzących do stron phishingowych;
• zmiana istotnych informacji, np. numerów rachunków bankowych;
• modyfikacja elementów interfejsu w sposób mogący wprowadzać użytkowników w błąd.

Nie każda zmiana oznacza jednak cyberatak. Przyczyną różnicy może być również legalna aktualizacja, zmiana treści lub modyfikacja elementów dynamicznych. Dlatego ważne jest rozróżnianie autoryzowanych aktualizacji od anomalii wymagających analizy.

DORA: czy art. 10 wymaga wykrywania anomalii na stronach WWW?

DORA wymaga od objętych nią podmiotów finansowych mechanizmów szybkiego wykrywania nietypowych działań i incydentów ICT. Nie wskazuje jednak konkretnego systemu monitorowania stron internetowych jako obowiązkowego rozwiązania.

Kluczowe znaczenie ma art. 10 rozporządzenia (UE) 2022/2554, zatytułowany „Wykrywanie”.

Art. 10 ust. 1 DORA – szybkie wykrywanie nietypowych działań

Przepis wymaga od podmiotów finansowych mechanizmów pozwalających na szybkie wykrywanie nietypowych działań, problemów z wydajnością sieci ICT oraz incydentów związanych z ICT.

Obowiązek obejmuje również identyfikowanie potencjalnych istotnych pojedynczych punktów awarii. Mechanizmy wykrywania powinny być regularnie testowane.

W odniesieniu do stron WWW przykładem nietypowego działania może być:

• nieautoryzowana zmiana formularza logowania;
• umieszczenie podejrzanego skryptu na stronie;
• podmiana treści serwisu;
• modyfikacja elementów interfejsu, które mogą wpływać na bezpieczeństwo użytkowników.

Zewnętrzny monitoring integralności może dostarczać informacji o takich zmianach, jeżeli zostały objęte odpowiednim zakresem monitorowania.

Art. 10 ust. 2 DORA – progi alarmowe i automatyczne alertowanie

Art. 10 ust. 2 określa wymagania dotyczące mechanizmów wykrywania. Powinny one umożliwiać stosowanie wielopoziomowej kontroli, definiowanie progów alarmowych oraz ustalanie kryteriów uruchamiania procesów reagowania na incydenty ICT.

Przepis przewiduje również automatyczne mechanizmy ostrzegawcze dla odpowiednich pracowników odpowiedzialnych za reagowanie na incydenty.

W praktyce nie wystarczy samo wykrycie nieoczekiwanej zmiany strony. Organizacja powinna określić:

• które zmiany wymagają analizy;
• jak są klasyfikowane i priorytetyzowane;
• kto otrzymuje alert;
• kiedy należy uruchomić procedurę reagowania.

Przykładowo istotna zmiana wyglądu strony logowania instytucji finansowej może wymagać innego poziomu reakcji niż drobna modyfikacja treści informacyjnej.

Art. 10 ust. 3 DORA – monitorowanie anomalii ICT i cyberataków

Ustęp 3 odnosi się do zapewnienia odpowiednich zasobów i zdolności do monitorowania aktywności użytkowników, występowania anomalii ICT oraz incydentów związanych z ICT, w szczególności cyberataków.

Zewnętrzna obserwacja stron WWW może uzupełniać monitoring infrastruktury, aplikacji i zdarzeń bezpieczeństwa, dostarczając informacji o zmianach widocznych dla użytkowników.

Nie zastępuje jednak monitorowania aktywności użytkowników, analizy logów ani innych mechanizmów wykrywania wymaganych w ramach szerszego systemu zarządzania ryzykiem ICT.

Art. 23 rozporządzenia 2024/1774 – szczegółowe wymagania wykrywania anomalii

Istotnym uzupełnieniem DORA jest art. 23 rozporządzenia delegowanego Komisji (UE) 2024/1774.

Przepis rozwija wymagania dotyczące wykrywania nietypowych działań oraz reagowania na incydenty ICT.

Obejmuje między innymi:

• określenie ról i odpowiedzialności za wykrywanie anomalii;
• gromadzenie, monitorowanie i analizowanie czynników wewnętrznych i zewnętrznych;
• uwzględnianie potencjalnych zagrożeń cybernetycznych i scenariuszy ataków;
• wykorzystywanie informacji o incydentach przekazywanych przez dostawców usług ICT;
• identyfikowanie nietypowych działań i zachowań;
• stosowanie narzędzi generujących ostrzeżenia, w szczególności w odniesieniu do zasobów wspierających funkcje krytyczne lub istotne.

Znaczenie ma również dokumentowanie zdarzeń. Rejestry powinny umożliwiać odtworzenie informacji o anomalii, w tym ustalenie jej rodzaju oraz czasu wystąpienia i wykrycia. Należy również chronić zgromadzone informacje i dowody przed nieuprawnionym dostępem lub manipulacją.

Z perspektywy compliance ważne jest więc nie tylko wykrycie nieautoryzowanej zmiany WWW, lecz także możliwość jej oceny, dokumentowania i przekazania do właściwego procesu reagowania.

Zewnętrzny monitoring integralności może wspierać takie mechanizmy jako dodatkowe źródło informacji o anomaliach. Jego rzeczywiste znaczenie zależy jednak od rodzaju monitorowanych zasobów, oceny ryzyka i integracji z systemem bezpieczeństwa organizacji.

NIS2 i KSC: jakie obowiązki dotyczą monitorowania bezpieczeństwa WWW?

Dyrektywa NIS2 i polska ustawa o krajowym systemie cyberbezpieczeństwa ustanawiają wymagania dotyczące zarządzania ryzykiem cyberbezpieczeństwa, stosowania odpowiednich środków bezpieczeństwa oraz obsługi incydentów.

Nie oznacza to powszechnego obowiązku stosowania określonego systemu monitorowania każdej strony internetowej. Wykrywanie nieautoryzowanych zmian może jednak stanowić uzasadniony element ochrony serwisów, których kompromitacja powodowałaby istotne ryzyko.

NIS2 art. 21 – zarządzanie ryzykiem i obsługa incydentów

Art. 21 dyrektywy NIS2 (UE) 2022/2555 określa obowiązek stosowania odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych w celu zarządzania ryzykiem dla bezpieczeństwa sieci i systemów informatycznych.

Wśród wymaganych obszarów znajdują się między innymi:

• polityki analizy ryzyka i bezpieczeństwa systemów informatycznych;
• obsługa incydentów;
• ciągłość działania i zarządzanie kryzysowe;
• bezpieczeństwo łańcucha dostaw;
• bezpieczeństwo systemów i sieci;
• polityki i procedury oceny skuteczności środków zarządzania ryzykiem.

W praktyce ochrona publicznych serwisów internetowych powinna wynikać z oceny ryzyka oraz znaczenia danego zasobu dla działalności organizacji.

Dla niektórych podmiotów strona WWW pełni przede wszystkim funkcję informacyjną. Dla innych stanowi istotny kanał świadczenia usług, obsługi klientów, uwierzytelniania lub przetwarzania danych.

Dlatego szczególnej uwagi wymagają strony logowania, formularze, portale klientów oraz serwisy wykorzystywane do świadczenia usług cyfrowych.

Rozporządzenie wykonawcze 2024/2690 – monitorowanie i rejestrowanie zdarzeń

Dodatkowe znaczenie dla wskazanych kategorii podmiotów ma rozporządzenie wykonawcze Komisji (UE) 2024/2690.

W załączniku, pkt 3.2, określono wymagania dotyczące monitorowania i rejestrowania działań w sieciach i systemach informatycznych.

Obejmują one między innymi:

• stosowanie procedur i narzędzi do monitorowania zdarzeń;
• wykrywanie zdarzeń mogących stanowić incydenty;
• automatyzację monitorowania, o ile jest to wykonalne;
• ograniczanie liczby wyników fałszywie dodatnich i fałszywie ujemnych;
• określanie progów alarmowych;
• inicjowanie odpowiedniej reakcji na wykryte alarmy;
• ochronę rejestrów przed nieuprawnionym dostępem i zmianami;
• synchronizację czasu oraz możliwość korelowania zdarzeń.

Należy pamiętać, że szczegółowe wymagania tego rozporządzenia dotyczą określonych kategorii podmiotów cyfrowych objętych jego zakresem. Nie można automatycznie przenosić ich na wszystkie organizacje podlegające NIS2.

KSC po nowelizacji z 2026 roku

3 kwietnia 2026 r. weszła w życie nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, opublikowana jako Dz.U. 2026 poz. 252.

Przepisy nowelizujące rozszerzają i modyfikują krajowe ramy cyberbezpieczeństwa, w tym zasady dotyczące podmiotów kluczowych i ważnych, zarządzania ryzykiem, stosowania środków bezpieczeństwa oraz obsługi i zgłaszania incydentów.

Dla organizacji korzystających z publicznych serwisów internetowych istotne jest ustalenie, czy ich kompromitacja mogłaby wpłynąć na świadczenie usług, bezpieczeństwo danych lub inne chronione zasoby.

Przykładowo podmiana zawartości portalu podmiotu objętego KSC może być sygnałem do wszczęcia analizy incydentu. Monitoring integralności wspiera wówczas wykrywanie objawów potencjalnego naruszenia, ale sam nie rozstrzyga jego charakteru prawnego ani obowiązku zgłoszenia.

Należy również uwzględnić przepisy przejściowe i terminy dostosowawcze właściwe dla poszczególnych kategorii podmiotów.

Jakie zagrożenia może wykrywać monitoring integralności stron WWW?

Monitoring integralności pozwala obserwować wybrane zmiany w publicznej warstwie serwisu internetowego, których nie musi ujawniać standardowy monitoring dostępności.

Taką perspektywę wykorzystuje między innymi system wIDS (Website Intrusion Detection System) rozwijany przez Monit24 .

Defacement i monitoring wizualny SSIM

Defacement polega na nieautoryzowanej zmianie wyglądu lub treści strony, np. zastąpieniu jej komunikatem atakującego albo modyfikacji istotnych elementów interfejsu.

Jedną z metod wykrywania takich zmian jest SSIM (Structural Similarity Index Measure). To metoda oceny podobieństwa strukturalnego obrazów, która może służyć do porównywania wyglądu strony między kolejnymi pomiarami.

Monitoring wizualny może ujawnić nieoczekiwaną zmianę, mimo że serwer nadal działa, a użytkownicy mogą otworzyć witrynę.

Sam sygnał nie przesądza jednak, że doszło do ataku. Przyczyną różnicy może być również legalna aktualizacja, zmiana elementów dynamicznych lub modyfikacja treści.

Dlatego istotne jest odpowiednie skonfigurowanie zakresu monitorowania i interpretowanie wykrytych różnic w kontekście charakteru serwisu.

Złośliwy JavaScript i web skimming

Nie każdy atak powoduje widoczną modyfikację wyglądu strony.

Atakujący może dodać skrypt przechwytujący dane wpisywane do formularza lub manipulujący jego zachowaniem. W przypadku formularzy płatniczych takie zagrożenie może być związane z web skimmingiem.

Złośliwy kod może działać w tle, bez widocznej zmiany interfejsu. Dlatego wykrywanie zmian WWW powinno uwzględniać również analizę skryptów, a nie wyłącznie wizualne porównywanie stron.

Według materiałów produktowych Monit24 wIDS wykorzystuje mechanizmy analizy JavaScriptu oraz modele uczenia maszynowego do identyfikowania podejrzanych cech skryptów.

Takie podejście może uzupełniać monitoring wizualny, pozwalając zwracać uwagę również na zmiany niewidoczne dla użytkownika.

Podejrzane linki, phishing i podmiana treści

Innym scenariuszem jest umieszczenie na legalnej stronie linku prowadzącego do witryny phishingowej albo nieautoryzowana zmiana informacji, np. numeru rachunku bankowego.

Monitoring treści i odnośników może wskazać takie odstępstwo i uruchomić dalszą analizę.

Nie oznacza to jednak automatycznego ustalenia sprawcy, sposobu włamania ani pełnego zakresu kompromitacji.

Wykrycie zmiany powinno być traktowane jako sygnał do weryfikacji, a nie jako samodzielne rozstrzygnięcie o przyczynie zdarzenia.

Więcej informacji:

• wIDS – monitoring zmian i anomalii na stronach internetowych
• Monitoring wizualny SSIM i wykrywanie defacementu

Kiedy nieautoryzowana zmiana strony WWW może wymagać zgłoszenia incydentu?

Wykrycie anomalii nie oznacza automatycznie, że doszło do incydentu podlegającego zgłoszeniu.

Organizacja musi najpierw ustalić charakter zdarzenia, jego wpływ na usługi i dane oraz ocenić właściwe kryteria prawne.

Przykładowo różnica w wyglądzie strony może wynikać z legalnej aktualizacji. Z kolei nieautoryzowana zmiana formularza płatniczego lub wstrzyknięcie skryptu przechwytującego dane może wskazywać na poważniejszy problem bezpieczeństwa.

Proces reagowania można uporządkować następująco:

1. Wykrycie – system identyfikuje podejrzaną zmianę i generuje alert.
2. Weryfikacja – zespół ustala, czy modyfikacja była autoryzowana i czy nie wynika z prawidłowej aktualizacji.
3. Analiza skutków – oceniany jest wpływ na systemy, usługi, dane i użytkowników.
4. Klasyfikacja – organizacja ustala, czy zdarzenie spełnia kryteria incydentu oraz czy podlega zgłoszeniu na podstawie właściwych przepisów.
5. Reakcja – podejmowane są działania techniczne, zabezpiecza się dowody i dokonuje ewentualnego zgłoszenia.

Ważne jest, aby informacje o wykrytej zmianie można było powiązać z innymi źródłami danych, takimi jak logi aplikacyjne, zdarzenia z WAF czy aktywność kont administracyjnych.

DORA, NIS2, KSC i RODO – co z terminami raportowania?

Poszczególne regulacje ustanawiają odrębne zasady raportowania. Nie można stosować jednego terminu do wszystkich incydentów i organizacji.

W przypadku DORA szczegółowe terminy raportowania określa również rozporządzenie delegowane Komisji (UE) 2025/301.

W przypadku NIS2 trzeba pamiętać, że procedura obejmuje nie tylko wczesne ostrzeżenie i zgłoszenie, ale również sprawozdanie końcowe.

Skrócenie czasu wykrycia nieautoryzowanej zmiany może ułatwić analizę, zabezpieczenie dowodów i terminowe podjęcie decyzji o zgłoszeniu. Nie oznacza jednak, że każdy alert automatycznie rozpoczyna bieg prawnego terminu raportowania.

W przypadku złośliwego kodu JavaScript przechwytującego dane z formularza konieczna może być także analiza obowiązków wynikających z art. 32–34 RODO, w szczególności gdy doszło do naruszenia ochrony danych osobowych.

Czy wIDS może uzupełniać WAF, SOC i SIEM?

Skuteczna architektura bezpieczeństwa wykorzystuje mechanizmy odpowiadające za różne etapy wykrywania i reagowania.

• WAF służy przede wszystkim ochronie ruchu aplikacyjnego i filtrowaniu potencjalnie złośliwych żądań.
• SIEM gromadzi i koreluje zdarzenia pochodzące z różnych systemów.
• SOC prowadzi operacyjną analizę zagrożeń i koordynuje działania związane z bezpieczeństwem.
• Monitoring integralności WWW obserwuje zmiany widoczne w publicznej warstwie serwisu.

Zewnętrzny monitoring integralności może uzupełniać te mechanizmy, dostarczając sygnałów o zmianach, które nie muszą być widoczne w standardowych testach dostępności.

Według informacji produktowych Monit24 wIDS wykorzystuje między innymi:

• analizę zmian wizualnych z wykorzystaniem SSIM;
• analizę anomalii;
• modele uczenia maszynowego;
• analizę skryptów JavaScript;
• mechanizmy ograniczania fałszywych alarmów;
• API umożliwiające integrację z platformami bezpieczeństwa, w tym SIEM/SOAR/XDR.

Przykładowo alert o zmianie strony logowania może zostać zestawiony z logami aplikacyjnymi, zdarzeniami z WAF oraz informacjami o aktywności administratorów.

Pozwala to uzyskać szerszy obraz zdarzenia i ułatwić jego analizę.

WIDS nie zastępuje jednak WAF, SIEM, SOC ani skanowania podatności. Monitoring skutków potencjalnego ataku nie jest równoznaczny z identyfikacją jego przyczyny.

Zewnętrzny monitoring ma również swoje ograniczenia. Obserwuje zasoby objęte zakresem pomiarów, może generować alerty związane z legalnymi aktualizacjami i nie musi wykrywać każdej zmiany zachodzącej wewnątrz infrastruktury lub aplikacji.

Dlatego powinien być traktowany jako dodatkowe źródło informacji, a nie samodzielny system zapewniający pełną ochronę serwisu.

Sam fakt wdrożenia monitoringu integralności WWW nie oznacza spełnienia wymagań DORA, NIS2 ani KSC. Zgodność regulacyjna wymaga odpowiednio zaprojektowanych procesów zarządzania ryzykiem, wykrywania, klasyfikacji, dokumentowania i reagowania na incydenty.

Z perspektywy regulacyjnej wartość takiego monitoringu należy więc oceniać jako część szerszego systemu zarządzania ryzykiem ICT i cyberbezpieczeństwa.

Checklista dla CISO: czy Twoja organizacja wykrywa nieautoryzowane zmiany stron WWW?

Poniższe pytania pozwalają wstępnie ocenić, czy mechanizmy monitorowania bezpieczeństwa serwisów internetowych odpowiadają zidentyfikowanym zagrożeniom.

Zasoby i ryzyko

• Czy posiadamy aktualny wykaz publicznych stron i aplikacji WWW?
• Czy znamy serwisy wspierające funkcje krytyczne lub istotne?
• Czy identyfikujemy formularze przetwarzające dane osobowe i finansowe?
• Czy analizujemy ryzyko nieautoryzowanych zmian treści i skryptów?

Monitoring integralności

• Czy kontrolujemy integralność stron niezależnie od ich dostępności?
• Czy możemy wykrywać defacement i nietypowe zmiany wizualne?
• Czy monitorujemy podejrzane zmiany JavaScriptu i formularzy?
• Czy identyfikujemy nieautoryzowane linki i przekierowania?

Alertowanie i reakcja

• Czy określiliśmy kryteria i progi alarmowe?
• Czy istotne alerty trafiają do właściwych osób?
• Czy istnieje procedura weryfikacji zmian?
• Czy możemy korelować alerty WWW z danymi SOC lub SIEM?

Incydenty i compliance

• Czy dokumentujemy możliwy do ustalenia czas wystąpienia i wykrycia anomalii?
• Czy potrafimy zabezpieczać dowody techniczne?
• Czy mamy procedurę klasyfikacji incydentów?
• Czy znamy właściwe organy oraz terminy zgłoszeń?

Skuteczność zabezpieczeń

• Czy regularnie testujemy skuteczność detekcji?
• Czy analizujemy fałszywe alarmy i niewykryte zdarzenia?
• Czy ponawiamy ocenę mechanizmów po zmianach infrastruktury?
• Czy potrafimy wykazać, w jaki sposób monitoring wspiera zarządzanie ryzykiem?

Odpowiedzi „Nie” lub „Nie wiem” wskazują obszary wymagające oceny, ale nie oznaczają automatycznie naruszenia przepisów. Checklista nie zastępuje formalnego audytu zgodności.

Podsumowanie: monitoring integralności WWW jako element systemu cyberbezpieczeństwa

Strona internetowa może działać poprawnie, mimo że jej zawartość została zmodyfikowana przez cyberprzestępców. Dlatego standardowe monitorowanie dostępności nie wystarcza do obserwowania wszystkich zagrożeń związanych z publicznymi serwisami internetowymi.

DORA, NIS2 i KSC wymagają od objętych nimi organizacji odpowiednich mechanizmów zarządzania ryzykiem, wykrywania zagrożeń i obsługi incydentów. Nie narzucają jednak powszechnego obowiązku korzystania z konkretnego rozwiązania do monitorowania integralności stron WWW.

Zewnętrzny monitoring może dostarczać dodatkowych informacji o nieautoryzowanych zmianach, defacementcie, podejrzanych skryptach i modyfikacjach treści. W połączeniu z WAF, SIEM, SOC oraz procedurami reagowania pomaga szybciej identyfikować potencjalne zagrożenia i oceniać ich skutki.

Najważniejsze jest połączenie obserwacji technicznej z właściwą reakcją organizacji. Wykrycie anomalii to początek procesu bezpieczeństwa, a nie jego zakończenie.