System po EOL to nie dług techniczny. To wpis w rejestrze ryzyka

Prawie każda firma ma jakiś system po EOL. Stary serwer z aplikacją, której nikt nie umie już przenieść, dystrybucja, która przestała dostawać aktualizacje dwa lata temu, urządzenie, którego producent dawno zniknął z rynku. Zwykle traktuje się to jak dług techniczny: coś, co kiedyś trzeba będzie posprzątać, na razie działa, więc niech działa.

To jest błąd kategorii. System po end-of-life to nie zaległość na liście zadań. To decyzja o ryzyku, którą ktoś podejmuje, świadomie albo nie, każdego dnia, kiedy ten system dalej stoi.

Dlaczego EOL zmienia charakter problemu

System z bieżącym wsparciem, w którym znajduje się podatność, ma ścieżkę wyjścia: producent wyda łatkę, Ty ją zainstalujesz, temat zamknięty. To normalny cykl i nie jest ryzykiem, tylko pracą.

System po EOL traci standardową ścieżkę bezpłatnego wsparcia producenta. To nie zawsze znaczy, że poprawka nigdy się nie pojawi: czasem dostępne jest płatne wsparcie rozszerzone, backport od dostawcy lub rozwiązanie zewnętrzne. Każdą taką możliwość trzeba jednak potwierdzić dla konkretnego produktu. Realne opcje to aktualizacja lub migracja, wsparcie rozszerzone, środki kompensacyjne, czasowa akceptacja ryzyka albo wyłączenie systemu.

I to właśnie robi z EOL wpis do rejestru ryzyka, a nie zadanie techniczne. Zadanie techniczne ma rozwiązanie. Ryzyko trzeba czymś świadomie zarządzić.

"Zaraz to zmigrujemy" nie jest planem

Najczęstsza reakcja na EOL brzmi "wiemy, planujemy to zmigrować". Problem w tym, że to zdanie nie jest planem migracji. To intencja migracji, a intencja nie ma daty, właściciela ani kamieni milowych. Systemy "do zmigrowania w tym roku" potrafią stać po pięć lat, bo zawsze jest coś pilniejszego, a ryzyko z EOL jest ciche: nie boli, dopóki nie wybuchnie.

Audytor to wie i dlatego nie zadowoli się deklaracją. Zapyta o konkret, a konkret ma trzy elementy.

Trzy rzeczy, które audytor musi zobaczyć

Co ciekawe, żadna z nich nie jest techniczna. Audytor nie oczekuje, że zlikwidujesz EOL z dnia na dzień. Oczekuje, że masz to pod kontrolą, a kontrola wygląda tak:

Imienny właściciel ryzyka. Konkretna osoba, która wzięła to ryzyko na siebie. Nie "dział IT", nie "firma", tylko nazwisko. Chodzi o to, żeby istniał ktoś, kto odpowiada za decyzję i kto ma interes w tym, żeby jej pilnować. Ryzyko bez właściciela jest niczyje, a niczyje ryzyko nie jest zarządzane.

Akceptacja ograniczona w czasie. Decyzja o zostawieniu systemu po EOL musi mieć datę wygaśnięcia. Nie "akceptujemy to ryzyko", tylko "akceptujemy to ryzyko do końca trzeciego kwartału, potem decyzja jest podejmowana ponownie". Bezterminowa akceptacja to antywzorzec, bo w praktyce znaczy "zapominamy o tym na zawsze". Data wygaśnięcia wymusza powrót do tematu, zanim ryzyko cicho urośnie.

Plan wyjścia z kamieniami milowymi. Nie musi być skomplikowany, ale musi być konkretny: migracja, izolacja albo wyłączenie, z datami pośrednimi. "Do końca roku przenosimy aplikację na wspieraną wersję, do końca sierpnia mamy środowisko testowe" to plan. "Kiedyś to ogarniemy" to nie plan.

Te trzy rzeczy razem zamieniają EOL z ukrytej bomby w zarządzane, udokumentowane ryzyko. I to jest dokładnie to, czego wymaga podejście oparte na ryzyku w ISO 27001 czy NIS2: nie zero ryzyka, tylko świadome panowanie nad nim.

Środki kompensacyjne na czas przejściowy

Skoro system po EOL zostaje na jakiś czas, warto zmniejszyć jego ekspozycję. Typowe środki to segmentacja sieci, ograniczenie dostępu do niezbędnych usług, zdjęcie wystawienia do internetu, wzmożony monitoring lub wirtualne łatanie. Nie zastępują one poprawki, ale mogą ograniczyć prawdopodobieństwo i skutki wykorzystania podatności.

Kiedy zostawienie EOL jest racjonalne

Byłbym nieuczciwy, gdybym twierdził, że EOL zawsze trzeba natychmiast usuwać. Czasem świadome zostawienie systemu po EOL jest rozsądną decyzją. Odizolowana maszyna bez połączenia z siecią, sterująca urządzeniem, które i tak zostanie wycofane za rok, gdzie koszt migracji jest absurdalnie wysoki wobec realnego ryzyka, to uzasadniony kandydat do akceptacji. Sęk nie w tym, żeby EOL nie było. Sęk w tym, żeby jego istnienie było decyzją z podpisem, a nie zaniechaniem, o którym nikt nie pamięta.

Różnica między tymi dwoma jest cała. Pierwsze audytor przyjmie. Drugie to niezgodność.

W praktyce

Prowadzenie akceptacji ryzyka z właścicielem, datą wygaśnięcia i przypominaniem, kiedy termin się zbliża, ręcznie jest do zrobienia, ale łatwo o tym zapomnieć, a zapomniana akceptacja to znów bezterminowa akceptacja. Zbudowałem to jako część procesu: akceptacja EOL z właścicielem, ograniczona w czasie, która sama się zgłasza, gdy wygasa. Jeśli chcesz zobaczyć, jak wygląda taka time-boxed akceptacja, wejdź do demo.

System po EOL nie jest wstydem. Problemem jest brak jawnej decyzji i kontroli. Wpis w rejestrze ryzyka nie gwarantuje pozytywnego wyniku audytu, ale pokazuje właściciela, termin, środki kompensacyjne i plan wyjścia, czyli materiał potrzebny do oceny, czy ryzyko jest faktycznie zarządzane.

Źródła

• Oficjalne FAQ do ustawy o KSC
• NIST Cybersecurity Framework 2.0