Po zakończeniu procesu inwentaryzacji audytor przechodzi do kolejnego etapu audytu systemów operacyjnych – weryfikacji wykorzystywanych wersji oraz analizy ich cyklu życia pod kątem wsparcia producenta. Celem kontroli jest potwierdzenie, że organizacja korzysta wyłącznie z systemów operacyjnych objętych aktywnym wsparciem technicznym, które otrzymują aktualizacje bezpieczeństwa i spełniają wymagania producenta dotyczące bezpiecznej eksploatacji.
Po osiągnięciu końca cyklu życia (End of Life – EOL) lub końca wsparcia technicznego (End of Support – EOS) system operacyjny traci dostęp do poprawek bezpieczeństwa, aktualizacji funkcjonalnych oraz wsparcia producenta. W takiej sytuacji producent nie usuwa nowych podatności, a organizacja ponosi pełne ryzyko związane z dalszym użytkowaniem systemu.
Weryfikacja wersji systemów operacyjnych nie ogranicza się do odczytania numeru wersji. Audytor powinien sprawdzić, czy wykorzystywane wydania odpowiadają aktualnej polityce organizacji, czy producent nadal dostarcza dla nich poprawki bezpieczeństwa oraz czy organizacja ma plan migracji systemów, które zbliżają się do końca okresu wsparcia.
Dlaczego cykl życia systemu operacyjnego ma znaczenie?
Każdy producent oprogramowania określa czas, w którym zapewnia wsparcie techniczne dla swoich produktów. W tym czasie publikuje poprawki eliminujące błędy funkcjonalne i podatności bezpieczeństwa oraz wprowadza nowe mechanizmy ochrony.
Po zakończeniu okresu wsparcia producent przestaje publikować aktualizacje zabezpieczeń. Nie oznacza to jednak, że system przestaje działać – organizacja nadal może go uruchamiać i wykorzystywać w codziennej pracy. Problem polega na tym, że każda nowo wykryta luka bezpieczeństwa pozostaje niezałatana i może zostać wykorzystana przez osoby atakujące.
Historia cyberbezpieczeństwa pokazuje wiele przypadków, w których atakujący uzyskali dostęp do organizacji właśnie dzięki wykorzystaniu niewspieranych systemów operacyjnych. Cyberprzestępcy często wyszukują urządzenia działające pod kontrolą przestarzałych wersji systemów Windows lub Linux, ponieważ wiedzą, że producenci nie usuną już znanych podatności.
Korzystanie z niewspieranego systemu wpływa również na zgodność z wymaganiami norm i regulacji. Większość standardów bezpieczeństwa wymaga stosowania oprogramowania objętego wsparciem producenta. W wielu branżach korzystanie z systemów po zakończeniu ich cyklu życia może skutkować stwierdzeniem istotnej niezgodności podczas audytu.
Podstawowe pojęcia związane z cyklem życia oprogramowania
Podczas audytu należy prawidłowo interpretować informacje publikowane przez producentów. W dokumentacji dotyczącej cyklu życia produktów najczęściej występują następujące pojęcia:
General Availability (GA) oznacza moment oficjalnego udostępnienia produktu użytkownikom.
Mainstream Support określa podstawowy okres wsparcia, w którym producent dostarcza poprawki funkcjonalne i bezpieczeństwa oraz zapewnia wsparcie techniczne.
Extended Support oznacza rozszerzony okres wsparcia. W tym czasie producent zazwyczaj publikuje wyłącznie poprawki bezpieczeństwa, natomiast nie rozwija już funkcjonalności produktu.
End of Support (EOS) oznacza zakończenie standardowego wsparcia producenta.
End of Life (EOL) oznacza definitywne zakończenie cyklu życia produktu i wycofanie jego dalszego rozwoju.
Niektórzy producenci oferują również płatne programy przedłużonego wsparcia. Organizacja powinna jednak traktować je jako rozwiązanie przejściowe, a nie długoterminową strategię utrzymania systemów.
Zakres kontroli audytowej
Podczas weryfikacji audytor powinien ustalić, jakie wersje systemów operacyjnych organizacja wykorzystuje oraz czy producent nadal zapewnia dla nich wsparcie.
Analiza powinna obejmować wszystkie środowiska, niezależnie od ich przeznaczenia. Audytor powinien uwzględnić serwery produkcyjne, środowiska testowe, komputery użytkowników, urządzenia administracyjne, maszyny wirtualne oraz instancje uruchomione w chmurze.
Kontrola nie powinna ograniczać się wyłącznie do systemów Microsoft Windows. Równie istotna jest analiza dystrybucji Linux, ponieważ poszczególni producenci stosują różne modele wsparcia. Przykładowo, dystrybucje typu LTS zapewniają znacznie dłuższy okres utrzymania niż wydania standardowe.
W organizacjach korzystających z kontenerów audytor powinien również sprawdzić wersje obrazów bazowych oraz systemów operacyjnych wykorzystywanych przez hosty kontenerowe.
Metody weryfikacji
Pierwszym krokiem jest zebranie informacji o wszystkich wersjach systemów operacyjnych zidentyfikowanych podczas inwentaryzacji.
Dla każdego urządzenia należy określić:
- nazwę systemu operacyjnego,
- edycję,
- numer wersji,
- numer kompilacji,
- wersję jądra (Linux),
- datę instalacji,
- datę ostatniej aktualizacji,
- producenta,
- datę zakończenia wsparcia.
Uzyskane informacje należy porównać z oficjalnymi harmonogramami publikowanymi przez producentów.
W przypadku systemów Windows pomocne są narzędzia administracyjne umożliwiające odczyt wersji systemu, numeru kompilacji oraz poziomu aktualizacji. W środowiskach Linux informacje można uzyskać z plików systemowych, menedżerów pakietów oraz poleceń administracyjnych.
Duże organizacje bardzo często wykorzystują centralne systemy zarządzania konfiguracją, które automatycznie raportują wersje wszystkich systemów operacyjnych.
Co należy sprawdzić podczas audytu?
Podczas analizy nie wystarczy potwierdzić, że system jest objęty wsparciem producenta.
Audyt powinien odpowiedzieć również na następujące pytania.
Sprawdzenie, czy organizacja posiada politykę określającą dopuszczalne wersje systemów operacyjnych?
Czy istnieje harmonogram wymiany systemów zbliżających się do zakończenia wsparcia?
Informacja o tym, czy nowe systemy są wdrażane zgodnie z obowiązującymi standardami?
Użytkownicy mogą samodzielnie instalować inne wersje systemów?
Czy organizacja monitoruje komunikaty producentów dotyczące zakończenia wsparcia?
Czy środowiska testowe wykorzystują aktualne wersje systemów?
Obrazy maszyn wirtualnych są regularnie aktualizowane?
Czy systemy chmurowe korzystają z aktualnych obrazów referencyjnych?
Typowe niezgodności wykrywane podczas audytu
Jednym z najczęściej spotykanych problemów jest pozostawianie w środowisku systemów, których producent zakończył wsparcie kilka lat wcześniej. Dotyczy to szczególnie serwerów uruchomionych na potrzeby pojedynczych projektów oraz komputerów wykorzystywanych przez wyspecjalizowane urządzenia przemysłowe.
Kolejnym wyzwaniem jest korzystanie z wielu różnych wersji tego samego systemu operacyjnego. Audytorzy regularnie spotykają się z sytuacjami, w których organizacja utrzymuje kilka wydań tego samego systemu. Taka różnorodność utrudnia zarządzanie aktualizacjami, zwiększa koszty administracji oraz komplikuje utrzymanie jednolitych standardów bezpieczeństwa.
Nie mniej istotnym problemem pozostaje brak planu migracji. Organizacja może mieć świadomość zbliżającego się zakończenia wsparcia, ale mimo to nie podejmuje odpowiednio wcześnie działań prowadzących do wymiany systemu.
Warto również zwrócić uwagę na nieaktualne obrazy maszyn wirtualnych wykorzystywane podczas wdrażania nowych serwerów. W rezultacie każda nowa maszyna rozpoczyna pracę z nieaktualnym systemem operacyjnym, co już na początku zwiększa ryzyko związane z bezpieczeństwem środowiska..
Ocena ryzyka
Ryzyko związane z wykorzystywaniem niewspieranych systemów operacyjnych należy zazwyczaj klasyfikować jako wysokie lub krytyczne. Wynika to przede wszystkim z faktu, że systemy pozbawione wsparcia producenta są bardziej podatne na wykorzystanie znanych luk bezpieczeństwa, mogą nie spełniać wymagań wielu norm bezpieczeństwa oraz zwiększają prawdopodobieństwo skutecznego cyberataku.
Poziom ryzyka zależy jednak również od roli danego systemu w organizacji. Jeżeli niewspierany system pełni funkcję krytyczną, na przykład kontrolera domeny, serwera bazodanowego lub systemu finansowego, ryzyko należy uznać za krytyczne.
Rekomendowane działania naprawcze
Organizacja powinna opracować formalną politykę zarządzania cyklem życia systemów operacyjnych. Dokument powinien określać dopuszczalne wersje systemów, zasady ich wdrażania, harmonogram aktualizacji oraz sposób postępowania z systemami zbliżającymi się do końca wsparcia.
Sama polityka nie wystarczy jednak bez bieżącego monitorowania cyklu życia produktów. Organizacja powinna śledzić komunikaty producentów dotyczące zakończenia wsparcia i odpowiednio wcześnie planować projekty migracyjne. W praktyce planowanie wymiany systemów powinno rozpoczynać się na wiele miesięcy przed osiągnięciem daty End of Support.
Szczególnej uwagi wymagają również środowiska zwirtualizowane. Organizacja powinna regularnie aktualizować obrazy referencyjne wykorzystywane do tworzenia nowych maszyn. Dzięki temu uniknie sytuacji, w której nowy serwer rozpoczyna pracę z nieaktualnym systemem i od razu wymaga aktualizacji.
Nie zawsze jednak można od razu zastąpić niewspierany system. Jeżeli przyczyny techniczne lub biznesowe uniemożliwiają jego szybką migrację, organizacja powinna wdrożyć środki kompensujące ryzyko. Mogą one obejmować izolację sieciową, ograniczenie dostępu, ścisłe monitorowanie ruchu oraz dodatkowe mechanizmy ochronne. Należy przy tym pamiętać, że takie rozwiązania powinny pełnić jedynie funkcję tymczasową i nie zastępują docelowej migracji do wspieranego systemu.
Powiązanie z normami i dobrymi praktykami
Kontrola zgodności wersji systemów operacyjnych z cyklem życia producenta wspiera realizację wymagań dotyczących zarządzania aktywami, podatnościami oraz utrzymania bezpiecznej konfiguracji. Jest zgodna z zaleceniami ISO/IEC 27001:2022 w zakresie zarządzania technicznymi podatnościami, funkcjami Identify i Protect w NIST Cybersecurity Framework 2.0 oraz zabezpieczeniami CIS Controls v8 dotyczącymi zarządzania zasobami i podatnościami. Regularna analiza cyklu życia systemów pozwala ograniczyć ryzyko wynikające z wykorzystywania przestarzałego oprogramowania oraz wspiera planowanie modernizacji infrastruktury.
Podsumowanie
Weryfikacja wersji systemów operacyjnych oraz analiza cyklu życia producenta są jednymi z kluczowych elementów audytu bezpieczeństwa. Korzystanie z aktualnych i wspieranych systemów stanowi podstawowy warunek utrzymania odpowiedniego poziomu ochrony, ponieważ tylko takie środowiska otrzymują poprawki eliminujące nowe podatności i umożliwiają skuteczne reagowanie na pojawiające się zagrożenia.
Organizacja powinna posiadać pełną wiedzę o wersjach wykorzystywanych systemów, monitorować harmonogramy wsparcia producentów oraz planować migracje z odpowiednim wyprzedzeniem. Odkładanie wymiany systemów do momentu zakończenia wsparcia prowadzi do wzrostu ryzyka, zwiększa koszty utrzymania i może utrudnić spełnienie wymagań regulacyjnych.
W kolejnej części rozdziału omówione zostanie zarządzanie aktualizacjami i poprawkami bezpieczeństwa, które stanowi naturalne rozwinięcie procesu weryfikacji wersji systemów operacyjnych i pozwala utrzymać ich odporność na współczesne zagrożenia.
Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.
Link do formularza tutaj: https://beitadmin.pl/pomysly
Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).
