Zarządzanie podatnościami w środowisku OT - od identyfikacji do remediacji

W lutym 2021 operator stacji uzdatniania wody w Oldsmar na Florydzie zauważył, że kursor na ekranie HMI porusza się samodzielnie - ktoś zdalnie zmienił stężenie wodorotlenku sodu ze 100 do ponad 11 000 ppm. Atakujący wykorzystał TeamViewer działający na stacji z Windows 7, systemie bez wsparcia od stycznia 2020. Gdyby operator nie siedział akurat przy konsoli, skażona woda mogła trafić do 15 000 odbiorców.

Ten incydent nie wymagał wyrafinowanego exploit chain ani podatności zero-day. Wystarczyło niezaktualizowane oprogramowanie, współdzielone hasło i brak segmentacji - trzy problemy, które zarządzanie podatnościami powinno adresować na długo przed atakiem.

W środowiskach OT zarządzanie podatnościami to jeden z najtrudniejszych procesów do wdrożenia. Systemów nie można patchować na bieżąco, producent kontroluje harmonogram aktualizacji, a sam patch może naruszyć stabilność procesu technologicznego. Ten artykuł opisuje pełny cykl - od identyfikacji podatności po remediację lub zastosowanie kontroli kompensujących - z uwzględnieniem realiów, w których działają systemy automatyki przemysłowej.

Źródła: Forescout ICS Cybersecurity 2026, Claroty State of CPS Security 2025

Dlaczego OT to nie IT - specyfika zarządzania podatnościami w automatyce

W sieciach IT cykl patchowania mierzy się w dniach. Zespół bezpieczeństwa publikuje biuletyn, administratorzy testują poprawkę na grupie pilotażowej i wdrażają ją na produkcji. W OT ten sam proces może trwać miesiące - albo nie dojść do skutku w ogóle.

Różnica wynika z pięciu fundamentalnych ograniczeń:

Czynnik	Środowisko IT	Środowisko OT
Dostępność	Tolerancja przestojów (okna serwisowe)	Zero tolerancji - proces ciągły 24/7/365
Cykl życia	3-5 lat	15-25 lat, nierzadko dłużej
Kontrola aktualizacji	Administrator decyduje	Producent musi zatwierdzić patch
Testowanie	Środowisko testowe jest standardem	Środowisko testowe rzadko dostępne
Wpływ awarii	Utrata danych, przestój usług	Zagrożenie życia, środowiska, strat produkcyjnych

Brak możliwości patchowania “na żywo”

Sterownik PLC zarządzający procesem chemicznym lub linią produkcyjną nie może być zrestartowany między cyklami produkcyjnymi tak, jak serwer webowy. Wgranie nowego firmware wymaga:

• zatrzymania procesu lub przełączenia na sterowanie redundantne,
• przetestowania nowej wersji (najlepiej na identycznym stanowisku testowym),
• zatwierdzenia przez producenta, że poprawka jest kompatybilna z istniejącą konfiguracją,
• koordynacji z zespołem produkcyjnym i służbami utrzymania ruchu.

W praktyce planowane postoje serwisowe zdarzają się raz na 6-18 miesięcy. Oznacza to, że nawet krytyczna podatność z wynikiem CVSS 9.8 może pozostać niezałatana przez cały ten okres.

Zależność od producenta

W IT administratorzy sami decydują o harmonogramie patchowania. W OT producent kontrolera PLC, systemu DCS lub RTU musi oficjalnie zatwierdzić każdą aktualizację. Wielu producentów publikuje biuletyny bezpieczeństwa z opóźnieniem albo nie oferuje poprawek dla starszych modeli, które formalnie wciąż działają w instalacjach.

Cykl życia podatności w środowisku OT

Zarządzanie podatnościami w OT to proces ciągły, który obejmuje pięć etapów. Każdy z nich różni się od swojego odpowiednika w IT.

1. Identyfikacja - odkrywanie podatności

Źródła informacji o podatnościach w systemach przemysłowych:

• CISA ICS Advisories - w 2025 roku CISA opublikowała 508 biuletynów obejmujących 2 155 CVE. To pierwszy rok, w którym przekroczono 500 biuletynów. Średni wynik CVSS wzrósł z 6.44 w 2010 do 8.07 w 2025, co oznacza, że typowa ujawniona podatność przesunęła się z kategorii “średnia” do “wysoka”.
• Biuletyny producentów - Siemens ProductCERT, Schneider Electric PSIRT, Rockwell Automation publikują własne advisories, często wcześniej niż CISA.
• Bazy podatności - NVD (National Vulnerability Database), Exploit-DB, VulnDB.
• Katalog CISA KEV (Known Exploited Vulnerabilities) - lista podatności aktywnie wykorzystywanych w atakach. W 2025 roku 29 pozycji dotyczyło systemów ICS, z czego 16 (55%) przypadało na produkty Siemens.
• Pasywne skanowanie sieci OT - narzędzia takie jak Tenable OT Security, Claroty lub Nozomi Networks Guardian analizują ruch sieciowy i korelują znalezione urządzenia z bazami podatności bez aktywnego odpytywania kontrolerów.

2. Ocena - kontekstualizacja podatności

Sam wynik CVSS nie wystarczy do oceny ryzyka w środowisku OT. Podatność z CVSS 9.8 w kontrolerze odizolowanym w strefie bezpieczeństwa SIS (Safety Instrumented System) ma inne znaczenie niż ta sama podatność w HMI z dostępem do sieci korporacyjnej.

Ocena kontekstowa uwzględnia:

• Ekspozycję sieciową - czy urządzenie jest dostępne z sieci IT lub internetu?
• Krytyczność zasobu - czy kontroler zarządza procesem wpływającym na bezpieczeństwo ludzi (SIL-rated)?
• Dostępność exploita - czy istnieje publicznie dostępny kod exploitujący (PoC)?
• Aktywne wykorzystanie - czy podatność figuruje w katalogu CISA KEV?

3. Priorytetyzacja - SSVC zamiast samego CVSS

Tradycyjne podejście “patchuj wszystko z CVSS >= 7.0” nie sprawdza się w OT, gdzie patchowanie jest kosztowne i ryzykowne. CISA rekomenduje metodologię SSVC (Stakeholder-Specific Vulnerability Categorization), opracowaną wspólnie z Carnegie Mellon SEI.

SSVC ocenia pięć wymiarów i generuje jedną z czterech decyzji:

Decyzja SSVC	Znaczenie	Przykład w OT
Act	Natychmiastowa remediacja	KEV w HMI z dostępem do internetu
Attend	Remediacja w najbliższym oknie serwisowym	Wysoki CVSS, brak eksploitacji, ale urządzenie w strefie DMZ
Track*	Monitoruj, zaplanuj remediację	Znana podatność, urządzenie w strefie zamkniętej
Track	Obserwuj, brak natychmiastowych działań	Niska ekspozycja, brak PoC, urządzenie w strefie SIS

Pięć kryteriów oceny SSVC:

1. Status eksploitacji - czy podatność jest aktywnie wykorzystywana?
2. Wpływ techniczny - częściowy czy pełny kompromis systemu?
3. Automatyzowalność - czy exploitację można zautomatyzować?
4. Znaczenie misyjne - jak krytyczny jest system dla procesu?
5. Wpływ na bezpieczeństwo publiczne - czy kompromis może zagrozić ludziom?

4. Remediacja - patch, kontrola kompensująca lub akceptacja ryzyka

Po priorytetyzacji każda podatność wymaga jednej z trzech decyzji:

a) Zainstaluj poprawkę - gdy producent udostępnił zatwierdzoną aktualizację i możliwe jest jej wdrożenie w planowanym oknie serwisowym.

b) Zastosuj kontrolę kompensującą - gdy patchowanie jest niemożliwe lub zbyt ryzykowne. Opcje:

• Virtual patching - reguły IPS/IDS blokujące konkretny wektor exploitacji na poziomie sieci, bez ingerencji w urządzenie docelowe.
• Segmentacja sieci - izolacja podatnego urządzenia w osobnej strefie z ograniczonym dostępem (więcej o segmentacji).
• Filtrowanie protokołów - firewall przemysłowy przepuszczający wyłącznie autoryzowane komendy (np. odczyt rejestrów Modbus, blokada zapisów).
• Monitorowanie - zwiększenie poziomu detekcji: alerty na nietypowe zapytania, zmiany konfiguracji, nowe połączenia.
• Ograniczenie zdalnego dostępu - wyłączenie lub dodatkowe zabezpieczenie kanałów zdalnych (konfiguracja bezpiecznego dostępu).

c) Zaakceptuj ryzyko - formalnie udokumentowana decyzja, gdy ryzyko jest niskie (urządzenie w strefie izolowanej, brak exploita, niski wpływ). Wymaga okresowej rewizji.

5. Weryfikacja - potwierdzenie skuteczności

Po remediacji sprawdź, czy:

• poprawka została faktycznie zainstalowana (nie tylko zaplanowana),
• kontrola kompensująca działa zgodnie z założeniami,
• urządzenie funkcjonuje poprawnie po zmianie,
• nie pojawiły się nowe podatności jako efekt uboczny aktualizacji.

IEC 62443 - wymagania normatywne dla zarządzania podatnościami

Dwa dokumenty z rodziny IEC 62443 bezpośrednio adresują zarządzanie podatnościami:

IEC 62443-2-3 - zarządzanie łatkami w środowisku IACS

Raport techniczny IEC TR 62443-2-3:2015 definiuje pięciofazowy cykl zarządzania poprawkami:

1. Identyfikacja - śledzenie alertów bezpieczeństwa i biuletynów producentów
2. Priorytetyzacja - ocena ryzyka z uwzględnieniem kontekstu IACS
3. Testowanie - weryfikacja poprawki w środowisku testowym przed wdrożeniem produkcyjnym
4. Wdrożenie - instalacja poprawki z zachowaniem procedur zarządzania zmianą
5. Weryfikacja - potwierdzenie prawidłowego działania systemu po aktualizacji

Norma podkreśla, że zarządzanie poprawkami musi być zintegrowane z procesem zarządzania zmianą (change management) - każda modyfikacja systemu OT wymaga formalnego zatwierdzenia i dokumentacji.

IEC 62443-4-2 - wymagania bezpieczeństwa komponentów

Standard IEC 62443-4-2 definiuje wymagania techniczne, które producent komponentu powinien spełnić. Z perspektywy zarządzania podatnościami istotne są wymagania dotyczące:

• mechanizmów bezpiecznej aktualizacji firmware (podpis cyfrowy, weryfikacja integralności),
• wsparcia dla uwierzytelniania i autoryzacji (eliminacja domyślnych haseł),
• logowania zdarzeń bezpieczeństwa umożliwiających detekcję prób exploitacji.

Katalog CISA KEV i jego znaczenie dla OT

Katalog Known Exploited Vulnerabilities (KEV) to lista utrzymywana przez CISA na mocy dyrektywy BOD 22-01. Zawiera podatności, dla których istnieją dowody na aktywną eksploitację.

Dla środowisk OT katalog KEV pełni trzy funkcje:

1. Priorytetyzacja - jeśli podatność jest w KEV, oznacza to, że atakujący aktywnie ją wykorzystują. W środowisku OT taka podatność wymaga natychmiastowej kontroli kompensującej, nawet jeśli patchowanie nie jest możliwe.
2. Ocena ryzyka dostawców - jeśli producent kontrolera PLC ma wiele pozycji w KEV bez dostarczonych poprawek, to sygnał do eskalacji lub rozważenia alternatywnego dostawcy.
3. Compliance - organizacje podlegające regulacjom federalnym USA (FISMA, BOD 22-01) mają obowiązek remediacji KEV w określonych terminach. W Europie dyrektywa NIS2 nakłada analogiczne wymagania.

Według analizy Claroty Team82, 12% urządzeń OT w badanych organizacjach ma podatności figurujące w katalogu KEV, a 40% organizacji posiada przynajmniej część tych urządzeń z niezabezpieczonym dostępem do internetu.

Kontrole kompensujące - gdy patchowanie jest niemożliwe

W OT kontrole kompensujące to nie plan awaryjny - to standardowy element strategii. Dla wielu urządzeń z 15-25 letnim cyklem życia poprawki bezpieczeństwa nigdy nie zostaną wydane.

Macierz kontroli kompensujących

Kontrola	Mechanizm	Kiedy stosować	Ograniczenia
Virtual patching (IPS)	Reguły blokujące exploit na poziomie sieci	Znany wektor ataku, dostępny sygnatura	Nie chroni przed nowymi exploitami
Segmentacja sieci	Izolacja podatnego urządzenia w strefie z restrykcyjnymi regułami	Urządzenie nie wymaga szerokiego dostępu sieciowego	Wymaga przebudowy architektury
Filtrowanie protokołów	Firewall przemysłowy (DPI) przepuszczający tylko dozwolone komendy	Protokoły OT (Modbus, S7comm, EtherNet/IP)	Wymaga dokładnej znajomości normalnego ruchu
Monitorowanie anomalii	Alerty na odchylenia od baseline	Uzupełnienie każdej innej kontroli	Nie blokuje ataku, tylko go wykrywa
Wyłączenie zbędnych usług	Dezaktywacja nieużywanych portów, protokołów, interfejsów	Każde urządzenie OT	Wymaga analizy zależności
Hardening konfiguracji	Zmiana domyślnych haseł, wyłączenie serwisów webowych	Każde urządzenie OT	Nie adresuje podatności w firmware

Narzędzia wspierające zarządzanie podatnościami w OT

Skuteczny program zarządzania podatnościami wymaga narzędzi zaprojektowanych dla specyfiki środowisk przemysłowych. Trzy kategorie rozwiązań:

Platformy widoczności i identyfikacji podatności

• Tenable OT Security (dawniej Indegy) - łączy pasywne nasłuchiwanie z aktywnym odpytywaniem sterowników (w bezpieczny sposób, na poziomie ich natywnych protokołów). Koreluje wykryte urządzenia z bazą podatności i wspiera priorytetyzację opartą na kontekście.
• Claroty Platform - monitoruje komunikację OT, identyfikuje urządzenia i mapuje podatności. Oferuje integrację z procesem zarządzania ryzykiem (risk-based approach).
• Nozomi Networks Guardian - pasywne monitorowanie sieci OT z detekcją anomalii i oceną podatności. Korzysta z feedu OT Threat Intelligence do korelacji z najnowszymi zagrożeniami.

Analiza SBOM (Software Bill of Materials)

Rosnącym trendem jest wymaganie od producentów dostarczenia SBOM - listy komponentów oprogramowania w urządzeniu. SBOM umożliwia:

• automatyczną identyfikację podatnych bibliotek (np. Log4j w embedded systemach),
• śledzenie end-of-life komponentów,
• szybsze określenie, czy nowa CVE dotyczy urządzeń w instalacji.

Zarządzanie poprawkami

Narzędzia takie jak Tripwire, SolarWinds Patch Manager lub dedykowane moduły w platformach OT wspierają planowanie, testowanie i weryfikację poprawek z uwzględnieniem okien serwisowych.

Incydenty spowodowane niezałatanymi systemami

Historia cyberbezpieczeństwa OT dostarcza wielu przypadków, w których niezarządzane podatności doprowadziły do realnych konsekwencji.

WannaCry - maj 2017

Ransomware WannaCry wykorzystał exploit EternalBlue (MS17-010) - podatność w protokole SMBv1 systemu Windows. Poprawka Microsoftu była dostępna od marca 2017, ale organizacje z systemami OT opartymi na Windows XP i Windows 7 nie mogły jej zainstalować ze względu na brak wsparcia lub zależności od producenta systemu DCS/SCADA. Wśród ofiar znalazły się zakłady produkcyjne Honda, Renault-Nissan i brytyjski NHS.

Oldsmar Water Treatment - luty 2021

Atakujący uzyskał zdalny dostęp do HMI przez TeamViewer na stacji z Windows 7 (EOL od stycznia 2020). System nie miał uwierzytelniania wieloskładnikowego, wykorzystywał współdzielone hasła i nie był oddzielony od sieci publicznej. Incydent pokazał, jak kumulacja niezarządzanych podatności tworzy wektor ataku dostępny nawet dla mało zaawansowanego przeciwnika.

Podatności VPN w infrastrukturze OT - 2019-2025

Seria krytycznych podatności w rozwiązaniach VPN (Pulse Secure CVE-2019-11510, Fortinet CVE-2018-13379, Citrix CVE-2019-19781) była masowo eksploatowana przez grupy APT i ransomware do uzyskania dostępu do sieci OT. Wiele organizacji przemysłowych nie patchowało tych systemów przez miesiące, traktując VPN jako “urządzenie sieciowe IT”, a nie element krytycznej infrastruktury OT.

Checklist - budowanie programu zarządzania podatnościami w OT

• Przeprowadź inwentaryzację wszystkich zasobów OT - nie możesz zarządzać podatnościami urządzeń, o których nie wiesz
• Wdróż pasywne monitorowanie sieci OT z automatyczną korelacją podatności
• Skonfiguruj alerty na nowe biuletyny CISA ICS-CERT i producentów twoich urządzeń
• Zdefiniuj procedurę oceny podatności uwzględniającą kontekst OT (nie sam CVSS)
• Wdróż SSVC lub podobną metodologię priorytetyzacji
• Określ okna serwisowe i skoordynuj je z planami patchowania
• Dla każdej podatności bez dostępnej poprawki - zdefiniuj i udokumentuj kontrolę kompensującą
• Zapewnij środowisko testowe do weryfikacji poprawek przed wdrożeniem produkcyjnym
• Monitoruj katalog CISA KEV pod kątem podatności dotyczących twoich urządzeń
• Wymagaj SBOM od dostawców nowych urządzeń i systemów
• Zintegruj zarządzanie podatnościami z procesem zarządzania zmianą (IEC 62443-2-3)
• Przeprowadzaj okresowe przeglądy zaakceptowanych ryzyk i aktywnych kontroli kompensujących

Od identyfikacji do ciągłego doskonalenia

Zarządzanie podatnościami w OT to nie jednorazowy projekt, lecz ciągły proces. Jego skuteczność zależy od trzech elementów: aktualnej wiedzy o zasobach (inwentaryzacja), bieżącej informacji o zagrożeniach (threat intelligence) i zdolności do reagowania (procedury patchowania i kontrole kompensujące).

Organizacje, które traktują ten proces poważnie, nie eliminują wszystkich podatności - to niemożliwe przy cyklu życia urządzeń OT. Zamiast tego budują warstwowy system ochrony, w którym każda niezałatana podatność jest świadomie zarządzana: zidentyfikowana, oceniona, spriorytetyzowana i objęta odpowiednią kontrolą.

---

Źródła:

• CISA ICS Advisories Recap for 2025 - SOCRadar
• ICS Cybersecurity in 2026: Vulnerabilities and Path Forward - Forescout
• State of CPS Security: OT Exposures 2025 - Claroty
• CISA Stakeholder-Specific Vulnerability Categorization (SSVC)
• IEC TR 62443-2-3:2015 - Patch management in the IACS environment
• Importance and Challenges of OT Patching - ISA
• CISA Known Exploited Vulnerabilities Catalog
• DHS Recommended Practice for Patch Management of Control Systems