Dlaczego w OT nie aktualizuje się od ręki

W sieci biurowej aktualizacja to zwykle kwestia wieczornego okna i restartu. Zarządzanie podatnościami w OT rządzi się innymi prawami a składa się na to kilka istotnych powodów.

Po pierwsze, wersję oprogramowania często zatwierdza producent maszyny albo integrator, który ją uruchamiał. Zmiana firmware’u sterownika potrafi wtedy oznaczać wyjście poza zatwierdzoną konfigurację, a razem z nim poza gwarancję i poza czyjąś odpowiedzialność za to, że linia działa.

Okno wyznacza proces, nie kalendarz IT. Piec, który schodzi z temperatury przez 8 godzin, nie zrestartuje się w nocy z wtorku na środę dlatego, że tak byłoby najwygodniej.

W grę wchodzi jeszcze wiek urządzeń. W OT sprzęt pracuje 15 lat i dłużej. Tego typu sprzęty są żywotne i nie ma powodu, żeby je wymieniać póki działają. Sporej części podatności nie da się więc usunąć, skoro producent dawno przestał wydawać aktualizacje dla danej generacji.

To nie znaczy, że w OT się nie aktualizuje. Oznacza to, że decyzja o aktualizacji zależy od innych czynników i zmiennych oraz musi zapadać na podstawie innych danych.

Wysoka ocena nie znaczy, że trzeba zatrzymać linię

Ocena, którą widzisz w komunikacie, to ocena bazowa. Opisuje techniczne cechy samej podatności, nie poziom ryzyka u Ciebie. Ocenia nie uwzględnia tego gdzie stoi Twoje urządzenie, ani kto się z nim łączy. Standard CVSS przewiduje wprawdzie metryki środowiskowe, pozwalające przeliczyć wynik pod konkretne wdrożenie, ale dla nas w tej chwili istotne jest, że producenci publikują prawie wyłącznie ocenę bazową. O tym, jak pilna jest ta pozycja u Ciebie i czy w ogóle trafia na to-do, decydują cztery pytania, na które odpowiedzi w komunikacie nie znajdziesz.

Czy w ogóle mamy ten produkt i tę wersję. Komunikaty producentów wymieniają dziesiątki numerów katalogowych i zakresów wersji. Zanim cokolwiek zaplanujesz, musisz się upewnić czy komunikaty w ogóle dotyczą Ciebie.

Czy podatna funkcja jest włączona. Tu akurat październikowy komunikat jest wzorcowy i pięknie nam obrazuje w czym rzecz. Podatność siedzi w serwerze WWW sterownika. Jeżeli w Twojej konfiguracji ten serwer jest wyłączony, droga do podatności jest zamknięta, choć ocena w komunikacie dalej wynosi 9,6. Sama podatność zostaje przy tym w oprogramowaniu i wraca w momencie, w którym ktoś ten serwer włączy. Dlatego taka pozycja nie znika z listy, tylko schodzi na jej koniec.

Skąd funkcja jest dostępna. Inaczej sprawa wygląda w przypadku urządzenia widocznego wyłącznie ze stacji inżynierskiej w wydzielonej sieci, a inaczej z takim do którego może podłączyć się każdy komputer z sieci biurowej, bo tak wyszło przy wdrożeniu integracji z systemem produkcyjnym.

Co musi się wydarzyć, żeby ktoś to wykorzystał. W październikowym komunikacie część scenariuszy wymaga, żeby uprawniony użytkownik zaimportował przez interfejs WWW spreparowany plik rejestrowania przebiegów. Złośliwy kod wykonuje się wtedy w przeglądarce użytkownika, w jego zalogowanej sesji, i dopiero przez nią wykonuje operacje na sterowniku, w granicach uprawnień tej osoby. To zupełnie inna droga niż pakiet wysłany anonimowo z sieci. Prowadzi przez człowieka i jego stację roboczą (od razu widać większe zagrożenia prawda?). Reakcja też wygląda inaczej: obok zmiany w konfiguracji potrzebna jest rozmowa z serwisem i z utrzymaniem ruchu o tym, skąd biorą takie pliki.

Ten rachunek działa też w drugą stronę. Podatność z oceną 6,5 na urządzeniu widocznym z sieci do której dostęp ma połowa firmy, sterującym procesem, którego nie da się zatrzymać, bywa pilniejsza niż dziewiątka na panelu, który i tak jest odcięty.

A jeżeli dla którejś z podatności pojawi się informacja, że jest realnie wykorzystywana w atakach, cały powyższy rachunek idzie do kosza i zostaje jedno pytanie: jak szybko da się zamknąć drogę do tej podatności. Czasem będzie to odcięcie urządzenia, częściej wyłączenie podatnej funkcji, zawężenie dostępu do dwóch stacji albo wyproszone u produkcji okno poza kolejnością ;).

Wszystko powyżej zakłada jednak, że wiesz, co masz. Bez listy urządzeń, wersji firmware’u i tego, co jest skąd osiągalne, nie ocenisz ani pierwszego pytania, ani trzeciego. W wielu zakładach to jest właśnie moment, w którym przegląd podatności się kończy, bo lista jest w głowie jednego automatyka albo w arkuszu sprzed reorganizacji. To nieprzyjemne, ale warto o tym wiedzieć przed wypłynięciem podatności, a nie w trakcie.

Kiedy producent nie ma poprawki

To sytuacja, z którą w OT trzeba się liczyć zawsze, i  chyba najbardziej praktyczna część tego tekstu. Siemens w październiku pokazał, jak to powinno wyglądać, bo wobec braku poprawki sam napisał, co zrobić w zamian.

Usuń funkcję, jeśli nikt jej nie używa. Wyłączenie serwera WWW w sterowniku, który obsługujesz przez oprogramowanie inżynierskie, zamyka drogę do podatności bez aktualizowania czegokolwiek. To najtańszy możliwy ruch i warto go sprawdzić jako pierwszy.

Ogranicz dostęp. Jeżeli funkcja jest potrzebna, zadajmy pytanie, komu. Dostęp do portów 80 i 443 tego sterownika z dwóch stacji inżynierskich to co innego niż dostęp z każdego komputera w firmie. Tutaj pracuje segmentacja sieci i reguły na firewallu, a przy dostępie zdalnym serwisu albo integratora także uwierzytelnianie wieloskładnikowe i konta imienne zamiast wspólnych.

Ogranicz, co może wjechać. Zalecenie, żeby wgrywać wyłącznie zaufane pliki diagnostyczne, nie jest widzimisię jakiegoś służbisty. To jest naprawdę istotna kwestia do przekazania ludziom, którzy obsługują te urządzenia, i element procedury serwisowej. Zabezpieczenia kompensacyjne nie zawsze są techniczne.

Zobacz, kiedy ktoś próbuje się dostać. Skoro wiesz, że dana ścieżka jest podatna i zostawiasz ją otwartą dla dwóch stacji, warto wiedzieć, kiedy pojawi się na niej ruch z trzeciej. Alarm na konkretnym zdarzeniu jest tani i realnie skraca czas reakcji.

Jedna uwaga, o której łatwo zapomnieć przy pisaniu takich list: zabezpieczenie kompensacyjne też zmienia system. Wyłączenie serwera WWW, z którego utrzymanie ruchu codziennie odczytuje diagnostykę, jest jednocześnie zmianą konfiguracji sterownika i zmianą sposobu pracy ludzi, więc również potrzebuje momentu, w którym da się ją wprowadzić. Taką zmianę cofa się w minutę, a nieudaną aktualizację firmware’u  już niekoniecznie.

Kiedy poprawka jednak jest

Wtedy robota wygląda zwyczajnie, tylko wymaga więcej dyscypliny niż w IT. Okno uzgadnia się z produkcją, a nie wyznacza z kalendarza IT. Zanim aktualizacja pójdzie na całą produkcję, idzie test na stanowisko zapasowe albo na jednej linii, ścieżka wycofania musi być zapisana, a kopia konfiguracji i programu sterownika sprawdzona pod kątem tego, czy naprawdę da się ją odtworzyć. Pisaliśmy o tym przy okazji snapshotów i kopii zapasowych: kopia, której nigdy nie odtworzyłeś, pozostaje założeniem. W trakcie przydaje się pod telefonem człowiek, który zna proces, nie samo urządzenie.

Warto przy tym rozdzielić dwie rzeczy. Czym zajmujemy się najpierw, decyduje ryzyko: urządzenie wystawione szerzej i podatność łatwiejsza do wykorzystania idą przed resztą, niezależnie od wygody aktualizacji. Po drugie, jak to przeprowadzamy, decydują możliwości zakładu: harmonogram produkcji, dostępność stanowiska testowego, to, czy da się wejść najpierw na jedną linię. Pierwsze jest pytaniem o priorytet, drugie o wykonanie.

Odłożone nie znaczy zapomniane

To jest różnica, od której zależy, czy w ogóle zarządzasz ryzykiem, czy tylko je omijasz. Z zewnątrz oba przypadki wyglądają tak samo w końcu podatność jest, poprawki nie wdrożono.

Jest pisemna decyzja, a nie ustalenia spod ekspresu. Są wdrożone zabezpieczenia tymczasowe (konkretne!). Jest osoba z imieniem i nazwiskiem, która za tę pozycję odpowiada. I jest data ponownej oceny.

Warunki się zmieniają: producent wydaje poprawkę, pojawia się informacja o realnym wykorzystaniu podatności, ktoś przy okazji innego wdrożenia zmienia regułę na firewallu i urządzenie, które było widoczne z dwóch stacji, zaczyna być widoczne z całej sieci. Decyzja podjęta w październiku była słuszna w październiku. Pytanie brzmi, kto i kiedy sprawdzi, czy nadal jest.

Bez tych czterech elementów zostaje zdanie „wiemy o tym”, które nie jest ani decyzją, ani zabezpieczeniem.

Kto to właściwie decyduje

Do tej jednej decyzji potrzeba trzech informacji i niejednokrotnie ich ustalenie wymaga współpracy. Jak urządzenie jest wystawione i skąd da się je osiągnąć, wie IT. Co się stanie z procesem przy restarcie i ile naprawdę trwa powrót do produkcji, wie automatyk albo utrzymanie ruchu. Co mówi producent, jaka wersja jest zatwierdzona i czy zmiana nie wywraca gwarancji, wie ten, kto rozmawia z dostawcą maszyny.

To nie jest spór, tylko problem informacyjny. Żadna z tych osób, pytana osobno, nie ma kompletu danych do podjęcia sensownej decyzji, a pytanie zadane jednej z nich zwykle wraca z odpowiedzią „nie da się” albo „trzeba natychmiast”, zależnie od tego, kogo pytamy.

Praktyczny wniosek jest prosty: ustal, kto zbierze te trzy informacje i kto podpisze się pod wynikiem. Przegląd podatności bez wskazanej osoby odpowiedzialnej kończy się na etapie przesyłania komunikatu dalej.

Jak to robimy

Zarządzanie podatnościami w OT zaczynamy od tego, co to jest i skąd jest widoczne. Zanim pojawi się rozmowa o konkretnej podatności, potrzebujemy listy urządzeń z wersjami oraz obrazu tego, które z nich są osiągalne z sieci biurowej, które ze stacji inżynierskich, a które z zewnątrz przez dostęp serwisowy. Zwykle to pierwsze zestawienie nadaje ton dalszym rozmowom, bo okazuje się, że droga do sterownika jest krótsza, niż powinna.

Potem oceniamy konkretne pozycje według pytań z tego wpisu i dzielimy je na trzy kategorie: do aktualizacji w najbliższym oknie, do obłożenia zabezpieczeniami kompensacyjnymi, do świadomej akceptacji z datą przeglądu. Każda pozycja ma odpowiedzialnego i termin.

Sieć OT oddzielamy od reszty infrastruktury i porządkujemy dostęp zdalny dla serwisu i integratorów, bo to jest ta warstwa, na której da się ograniczyć ryzyko bez dotykania sterowników. Robimy to w ramach zabezpieczeń sieciowych i najczęściej razem z automatykami po stronie klienta, bo sami nie wiemy, co, kiedy i na ile wolno zatrzymać.

Pytania, na które warto znać odpowiedź

Czy da się w OT aktualizować na bieżąco, tak jak w IT?
Regularnie tak, odruchowo nie. Regularność w OT oznacza zaplanowane okna, znany cykl i śledzenie komunikatów producenta pomiędzy nimi. Czego nie da się przenieść z IT, to nawyku „wyszła poprawka, wgrywamy w nocy”, ponieważ tutaj każda instalacja przechodzi przez test i przez zgodę produkcji. Równie ważne jest, żeby wiedzieć, które podatności u Ciebie są, które z nich coś znaczą i co robisz z tymi, których nie zamykasz. Zakład, który aktualizuje dwa razy w roku w zaplanowanych oknach, a między nimi świadomie ogranicza dostęp, jest w lepszej sytuacji niż taki, który robi to zrywami i nie wie, co ma.

Skąd mam wiedzieć, że producent coś opublikował?
Najwięksi producenci systemów sterowania prowadzą własne kanały z komunikatami o podatnościach i udostępniają je w formie subskrypcji. Druga warstwa to publikacje CISA, która zbiera komunikaty dotyczące systemów przemysłowych od wielu producentów w jednym miejscu. Warto, żeby ktoś miał to w zakresie obowiązków, bo komunikat przeczytany trzy miesiące po publikacji nie jest wiele wart.

Co z urządzeniami, które nie są już wspierane?
Na nowe poprawki producenta zwykle nie ma już co liczyć, więc zabezpieczenia kompensacyjne przestają być rozwiązaniem tymczasowym i stają się docelowym, aż do wymiany urządzenia. Wymiana sterownika w pracującej linii to decyzja inwestycyjna na lata, a nie zadanie dla IT. Twoim zadaniem jest pokazać, co dokładnie zostaje nieosłonięte i co to oznacza, żeby ta decyzja zapadła świadomie.

Czy odłożona aktualizacja to problem przy audycie?
Problemem jest odłożenie bez zapisu. Audytor nie oczekuje, że w OT wszystko jest zaktualizowane, bo wie, że to niewykonalne. Chce zobaczyć, że ryzyko zostało ocenione, że ktoś je przyjął i że coś w tym temacie zrobiono. Sama dokumentacja niczego nie przesądza, ponieważ liczy się także to, czy pozostawione ryzyko mieści się w wymaganiach obowiązujących Twoją branżę. Daje jednak punkt wyjścia do rozmowy, którego bez niej po prostu nie ma. O tym, jak rozłożyć takie rzeczy na etapy, pisaliśmy przy okazji przygotowania organizacji do NIS2.

Czy aktualizacja może poczekać?

Czasem tak. Pod warunkiem że przez ten czas robisz coś innego.

Październik 2026 pokazał to na przykładzie, który trudno podważyć, bo pochodzi od samego producenta: przy jednej z najwyżej ocenionych podatności poprawki nie było, a zalecenie brzmiało „wyłącz, jeśli nie używasz, i ogranicz dostęp, jeśli używasz”. To jest dokładnie ta odpowiedź, której potrzebuje zakład produkcyjny. Nie „aktualizuj natychmiast” i nie „poczekaj, aż będzie poprawka”, tylko „zmniejsz to, co da się zmniejszyć dzisiaj, i wyznacz datę, kiedy wrócisz do sprawy”.

Jeżeli chcesz sprawdzić, które z Twoich urządzeń OT są osiągalne skąd i co z tego wynika, umów bezpłatną konsultację z naszym inżynierem. Zaczynamy od listy i od dróg dostępu, bo bez nich każda rozmowa o podatnościach jest zgadywaniem.