Czy regularne aktualizacje serwerów i urządzeń sieciowych są warte trudu?

Może jak działa, to nie ruszać?

„Jak działa, to nie ruszać” – to jedna z najbardziej znanych zasad funkcjonujących w informatyce.

I trzeba przyznać, że ma w sobie trochę zdrowego rozsądku.

Każda ingerencja w działający serwer, firewall, switch czy inne urządzenie infrastruktury IT wiąże się przecież z pewnym ryzykiem. Aktualizacja może wymagać restartu, może ujawnić problem z kompatybilnością aplikacji, a w skrajnym przypadku może spowodować przerwę w działaniu systemu.

Dlatego wielu przedsiębiorców zadaje całkiem racjonalne pytanie:

Skoro serwer działa, użytkownicy się nie skarżą, firewall przepuszcza ruch, VPN działa i firma normalnie pracuje – po co cokolwiek aktualizować?

Problem polega na tym, że w cyberbezpieczeństwie:

„działa” nie oznacza „jest bezpieczne”.

Serwer może działać poprawnie i jednocześnie posiadać znaną podatność.

Firewall może od lat bezawaryjnie obsługiwać internet, a jego firmware może zawierać podatność umożliwiającą atak z sieci publicznej.

Switch może nie sprawiać żadnych problemów użytkownikom, a jednocześnie korzystać z wersji oprogramowania, której producent już nie wspiera.

Dlatego dobre zarządzanie IT nie polega ani na bezrefleksyjnym aktualizowaniu wszystkiego, ani na pozostawianiu infrastruktury bez zmian przez wiele lat.

Polega na kontrolowanym zarządzaniu aktualizacjami i ryzykiem.

Czy zasada „jak działa, to nie ruszać” ma jeszcze sens w nowoczesnym IT?

W określonych sytuacjach ostrożność jest uzasadniona.

Administrator nie powinien aktualizować krytycznego serwera produkcyjnego tylko dlatego, że pojawiła się nowa wersja oprogramowania.

Nie powinien również instalować nowego firmware na firewallu w środku dnia roboczego bez analizy wpływu na działalność klienta.

Problem zaczyna się wtedy, gdy rozsądna ostrożność zmienia się w wieloletnie odkładanie aktualizacji.

Wtedy powstaje dług technologiczny.

System nadal działa, ale:

• pojawiają się kolejne znane podatności,
• producent przestaje wspierać używaną wersję,
• nowe aplikacje mogą przestać być z nią kompatybilne,
• aktualizacja staje się coraz bardziej skomplikowana,
• wykonanie późniejszego dużego upgrade’u staje się bardziej ryzykowne,
• administrator coraz mniej chętnie dotyka systemu, bo zmiana robi się coraz większa.

Paradoks polega więc na tym, że unikanie małych, kontrolowanych zmian może po kilku latach doprowadzić do konieczności wykonania jednej dużej i znacznie bardziej ryzykownej zmiany.

Dlaczego serwer, który działa bez awarii, może być niebezpieczny?

System operacyjny nie staje się podatny dlatego, że coś się w nim zepsuło.

Może działać idealnie.

Zmienia się natomiast nasza wiedza o sposobach jego atakowania.

Producent albo badacze bezpieczeństwa odkrywają podatność. Otrzymuje ona identyfikator CVE. Pojawia się analiza techniczna. Producent publikuje poprawkę.

Po pewnym czasie informacje dotyczące podatności mogą stać się publicznie dostępne.

Czasami pojawia się również gotowy exploit.

Wtedy ten sam serwer, który przez ostatnie dwa lata działał stabilnie, nadal działa dokładnie tak samo.

Ale zmieniło się otoczenie.

Cyberprzestępcy wiedzą już, jak wykorzystać jego podatność.

Dlatego z punktu widzenia cyberbezpieczeństwa infrastruktura musi być oceniana nie tylko pod kątem dostępności, ale również aktualności i występujących podatności.

Czy urządzenia sieciowe naprawdę trzeba aktualizować?

Tak.

To jeden z częstszych błędów spotykanych w firmowych środowiskach IT.

Organizacja regularnie aktualizuje komputery użytkowników i część serwerów, ale przez wiele lat nie aktualizuje:

• firewalli,
• routerów,
• switchy,
• kontrolerów Wi-Fi,
• access pointów,
• koncentratorów VPN,
• urządzeń storage,
• kontrolerów sprzętowych serwerów.

Tymczasem firewall czy switch również jest wyspecjalizowanym komputerem.

Posiada:

• procesor,
• pamięć,
• system operacyjny,
• firmware,
• interfejs administracyjny,
• usługi sieciowe,
• biblioteki kryptograficzne,
• mechanizmy uwierzytelnienia.

A więc również może posiadać podatności.

Dlaczego szczególnie ważne są aktualizacje firewalli i urządzeń dostępnych z internetu?

Firewall znajduje się najczęściej na granicy pomiędzy siecią firmową a internetem.

To oznacza, że jego podatność może być szczególnie atrakcyjna dla atakującego.

Jeżeli urządzenie udostępnia:

• VPN,
• panel administracyjny,
• portal użytkownika,
• usługę zdalnego dostępu,

atakujący może próbować wykorzystać podatność jeszcze zanim uzyska jakikolwiek dostęp do sieci wewnętrznej przedsiębiorstwa.

Dlatego inżynier Lizard, analizując infrastrukturę klienta, powinien zwracać szczególną uwagę na urządzenia wystawione bezpośrednio do internetu.

Jeżeli producent opublikował krytyczną aktualizację bezpieczeństwa, nie zawsze warto czekać do następnego standardowego cyklu aktualizacji.

Czasami konieczne jest przyspieszone działanie.

Czy każdą aktualizację należy instalować natychmiast?

Nie.

I jest to bardzo ważne.

Profesjonalny Patch Management nie oznacza:

„pojawiła się aktualizacja – natychmiast instalujemy”.

Inżynier Lizard powinien najpierw wykonać analizę.

Powinien sprawdzić między innymi:

• czego dotyczy aktualizacja,
• jakie podatności usuwa,
• czy podatność jest krytyczna,
• czy istnieją informacje o rzeczywistych atakach,
• czy urządzenie jest dostępne z internetu,
• jakie są zalecenia producenta,
• jakie są wymagania dotyczące ścieżki aktualizacji,
• czy znane są problemy z nową wersją,
• jaki wpływ aktualizacja może mieć na środowisko klienta.

Dopiero na tej podstawie można zaproponować termin i sposób wykonania zmiany.

Co powinien zrobić inżynier Lizard przed aktualizacją?

Aktualizacja powinna być przygotowaną zmianą techniczną.

Doświadczony inżynier Lizard powinien przede wszystkim poznać środowisko, które będzie aktualizowane.

W przypadku serwera może sprawdzić:

• rolę serwera,
• działające usługi,
• zależności aplikacji,
• stan systemu,
• wymagania producenta aplikacji,
• dostępność backupu,
• możliwość restartu.

W przypadku firewalla lub urządzenia sieciowego analiza może obejmować:

• obecną wersję firmware,
• konfigurację,
• urządzenia pracujące w HA,
• tunele VPN,
• połączenia między lokalizacjami,
• wykorzystywane moduły bezpieczeństwa,
• rekomendowaną przez producenta ścieżkę upgrade’u,
• możliwość powrotu do poprzedniej konfiguracji.

Na tej podstawie inżynier Lizard zaproponuje klientowi sposób przeprowadzenia aktualizacji oraz odpowiednie okno serwisowe.

Dlaczego przed aktualizacją trzeba wykonać backup?

Ponieważ nawet najlepiej przygotowana zmiana może nie przebiec zgodnie z planem.

Przed aktualizacją serwera inżynier Lizard powinien zweryfikować, czy istnieje poprawna kopia zapasowa systemu i danych.

W zależności od środowiska może być potrzebny:

• pełny backup,
• backup maszyny wirtualnej,
• kopia bazy danych,
• kopia systemu,
• snapshot wykorzystany jako element procesu technicznego,
• eksport konfiguracji.

Przed aktualizacją urządzenia sieciowego inżynier powinien wykonać kopię jego konfiguracji.

Dotyczy to szczególnie:

• firewalli,
• routerów,
• switchy zarządzalnych,
• kontrolerów Wi-Fi.

Backup nie może być jednak traktowany jako formalność.

Dobrze przygotowany inżynier powinien wiedzieć:

jak z tej kopii skorzystać, jeżeli aktualizacja zakończy się niepowodzeniem.

Czy aktualizację należy wykonywać podczas pracy firmy?

Jeżeli aktualizacja może mieć wpływ na użytkowników lub dostępność systemu – najczęściej nie.

Inżynier Lizard powinien uzgodnić z klientem termin, w którym zmiana spowoduje możliwie najmniejsze zakłócenia.

Może to oznaczać aktualizację:

• wieczorem,
• w nocy,
• w weekend,
• poza godzinami pracy przedsiębiorstwa,
• w ustalonym wcześniej oknie serwisowym.

Jeżeli klient pracuje w modelu wielozmianowym albo 24/7, konieczne może być zastosowanie bardziej zaawansowanego scenariusza.

Może on obejmować:

• przełączenie usług na drugi węzeł,
• wykorzystanie klastra,
• zastosowanie redundancji,
• aktualizację elementów infrastruktury po kolei.

Najważniejsze jest jedno:

termin aktualizacji powinien wynikać z charakteru biznesu klienta, a nie z wygody administratora.

Co to jest okno serwisowe?

Okno serwisowe to uzgodniony okres, w którym administrator może wykonywać zmiany potencjalnie wpływające na działanie infrastruktury.

Przykładowo klient może ustalić:

• drugą sobotę miesiąca,
• godziny 22:00–02:00,
• określony wieczór po zakończeniu pracy zakładu.

Regularne okna serwisowe mają bardzo dużą wartość.

Firma wie, kiedy mogą być wykonywane zmiany.

Inżynierowie mogą odpowiednio zaplanować pracę.

Użytkownicy otrzymują wcześniejszą informację.

Właściciele aplikacji mogą być dostępni po zakończeniu aktualizacji, żeby sprawdzić działanie swoich systemów.

Patch Management przestaje wtedy być serią przypadkowych ingerencji.

Staje się przewidywalnym procesem operacyjnym.

Jak powinien wyglądać profesjonalny proces aktualizacji?

Dobra aktualizacja zaczyna się dużo wcześniej niż od naciśnięcia przycisku „Update”.

Inżynier Lizard powinien kolejno:

1. zidentyfikować system lub urządzenie i jego obecną wersję,
2. przeanalizować dostępne aktualizacje,
3. ocenić ryzyko pozostawienia starej wersji,
4. ocenić ryzyko samej aktualizacji,
5. sprawdzić dokumentację producenta,
6. zweryfikować kompatybilność,
7. zaproponować klientowi sposób i termin wykonania prac,
8. uzgodnić okno serwisowe,
9. wykonać albo zweryfikować backup,
10. zabezpieczyć kopię konfiguracji,
11. przygotować plan wycofania zmiany,
12. wykonać aktualizację,
13. przeprowadzić restart, jeżeli jest wymagany,
14. wykonać testy techniczne,
15. potwierdzić działanie usług biznesowych,
16. monitorować środowisko po zmianie,
17. udokumentować wykonaną aktualizację.

Dopiero taki proces można nazwać zarządzaniem zmianą.

Dlaczego doświadczenie inżyniera jest ważne?

Samo przeczytanie instrukcji aktualizacji często nie wystarcza.

Doświadczony inżynier potrafi przewidzieć zależności, których nie widać na pierwszy rzut oka.

Przykład.

Aktualizacja firewalla może wyglądać jak prosta zmiana firmware.

Doświadczony inżynier sprawdzi jednak wcześniej:

• czy zmiana wpływa na tunele VPN,
• czy urządzenie współpracuje z drugim firewallem,
• czy zmienia się sposób obsługi określonych funkcji,
• czy producent wymaga wersji pośredniej,
• czy po aktualizacji trzeba wykonać migrację konfiguracji,
• czy nowa wersja ma zgłoszone znane błędy.

Analogicznie aktualizacja Windows Server może być prostym procesem technicznym, ale aplikacja działająca na tym serwerze może posiadać szczególne wymagania.

Dlatego wartość usługi nie polega wyłącznie na:

„zainstalowaniu aktualizacji”.

Polega przede wszystkim na bezpiecznym przeprowadzeniu zmiany w konkretnym środowisku biznesowym.

Co to jest rollback i dlaczego musi być zaplanowany wcześniej?

Rollback oznacza możliwość wycofania zmiany.

Każdy administrator przed rozpoczęciem poważnej aktualizacji powinien odpowiedzieć na pytanie:

„Co zrobimy, jeśli po aktualizacji system nie będzie działał?”

Odpowiedzią może być:

• powrót do poprzedniej wersji firmware,
• odtworzenie konfiguracji,
• przywrócenie serwera z backupu,
• rollback maszyny wirtualnej,
• przełączenie na drugi element klastra,
• wykorzystanie urządzenia zapasowego.

Najgorsza możliwa sytuacja występuje wtedy, gdy firma dopiero podczas awarii zaczyna zastanawiać się, czy istnieje możliwość powrotu do poprzedniej wersji.

Czy warto robić aktualizacje Windows Server regularnie?

Tak.

Systemy serwerowe powinny być objęte regularnym procesem Patch Management.

Nie oznacza to jednak konieczności aktualizowania wszystkich serwerów jednocześnie.

Dobre środowisko może mieć podział na grupy.

Najpierw można aktualizować:

• system testowy,
• serwery mniej krytyczne,
• wybraną grupę pilotażową.

Dopiero później systemy najbardziej krytyczne.

Pozwala to szybciej wykryć ewentualne problemy.

Czy każdy serwer powinien być restartowany?

Część aktualizacji wymaga restartu.

To jeden z najczęstszych powodów odkładania patchowania.

Firma mówi:

„Nie możemy teraz restartować ERP.”

Za miesiąc sytuacja wygląda podobnie.

Później mija pół roku.

W efekcie serwer ma coraz większą liczbę zaległych poprawek.

Jeżeli krytyczny system nie może być planowo zatrzymany nawet na krótki czas, warto zadać dodatkowe pytanie:

czy architektura zapewnia odpowiednią ciągłość działania?

Być może problemem nie jest wtedy aktualizacja.

Problemem jest brak redundancji albo źle zaprojektowany system wysokiej dostępności.

Czy zawsze warto instalować najnowszy firmware?

Nie.

„Najnowszy” nie zawsze oznacza „najlepszy do produkcji”.

Producenci mogą publikować:

• wersje stabilne,
• wersje rekomendowane,
• wersje Long-Term Support,
• wersje major zawierające nowe funkcje,
• poprawki bezpieczeństwa.

Doświadczony inżynier Lizard powinien ocenić, która wersja jest właściwa dla środowiska klienta.

W wielu przypadkach lepszym rozwiązaniem będzie instalacja rekomendowanej stabilnej wersji niż automatyczne przejście na najnowsze wydanie w dniu premiery.

Czy można przeskoczyć kilka wersji firmware?

Nie zawsze.

To szczególnie ważne przy urządzeniach sieciowych.

Producent może wymagać wykonania określonej ścieżki aktualizacji.

Przykładowo nie należy przechodzić bezpośrednio z bardzo starej wersji do najnowszej.

Konieczne mogą być wersje pośrednie.

Inżynier Lizard powinien przed aktualizacją sprawdzić dokumentację producenta i właściwą ścieżkę upgrade’u.

To jeden z powodów, dla których wieloletnie odkładanie aktualizacji zwiększa później zakres pracy i ryzyko zmiany.

Co zrobić, jeśli pojawi się krytyczna podatność?

Standardowe okno serwisowe nie zawsze wystarczy.

Jeżeli podatność:

• ma wysoki poziom krytyczności,
• dotyczy urządzenia dostępnego z internetu,
• posiada dostępny exploit,
• jest aktywnie wykorzystywana przez cyberprzestępców,

inżynier Lizard powinien przeanalizować potrzebę wykonania awaryjnej aktualizacji bezpieczeństwa.

Jeżeli aktualizacji nie da się natychmiast wykonać, można czasowo zastosować zabezpieczenia kompensujące.

Przykładowo:

• ograniczyć dostęp,
• wyłączyć podatną funkcję,
• zmienić reguły firewalla,
• ograniczyć dostęp administracyjny,
• odizolować system,
• zwiększyć monitoring.

Celem jest ograniczenie ryzyka do czasu wykonania właściwej poprawki.

Czy CVSS wystarcza do podjęcia decyzji?

Nie.

CVSS jest bardzo przydatnym wskaźnikiem technicznej krytyczności podatności.

Ale rzeczywiste ryzyko dla konkretnej organizacji zależy również od tego:

• gdzie znajduje się system,
• czy jest dostępny z internetu,
• jakie dane przetwarza,
• czy wymaga uwierzytelnienia,
• czy istnieje działający exploit,
• czy funkcjonują dodatkowe zabezpieczenia,
• jaki byłby wpływ przejęcia systemu na przedsiębiorstwo.

Dlatego profesjonalne zarządzanie aktualizacjami powinno być risk-based, czyli oparte na ryzyku.

Co zrobić ze starym systemem, którego nie można już aktualizować?

To częsty problem.

Przykładowo stary serwer może obsługiwać:

• system produkcyjny,
• specjalistyczną maszynę,
• starą aplikację ERP,
• oprogramowanie, którego producent już nie rozwija.

Nie zawsze można po prostu zainstalować najnowszą wersję systemu.

Nie oznacza to jednak, że należy powiedzieć:

„działa, więc zostawiamy”.

Inżynier Lizard powinien wykonać analizę ryzyka i zaproponować zabezpieczenia kompensujące.

Mogą to być między innymi:

• segmentacja sieci,
• ograniczenie dostępu,
• brak bezpośredniego dostępu do internetu,
• dodatkowe reguły firewalla,
• ograniczone konta administracyjne,
• dodatkowy monitoring,
• izolacja systemu.

Równolegle należy przygotować plan migracji.

System niewspierany przez producenta powinien być traktowany jako zarządzany wyjątek, a nie jako normalny stan infrastruktury.

Co oznacza EOL i dlaczego jest ważne?

EOL – End of Life – oznacza zakończenie cyklu życia produktu.

Jeszcze ważniejszy z punktu widzenia bezpieczeństwa jest moment zakończenia wsparcia.

Urządzenie może nadal działać przez wiele lat.

Jeżeli producent przestaje publikować poprawki bezpieczeństwa, pojawia się jednak zasadniczy problem.

Nowo odkrytej podatności może już nie być czym naprawić.

Wtedy rozwiązaniem nie jest patch.

Rozwiązaniem staje się:

upgrade, migracja albo wymiana urządzenia.

Czy switche i Wi-Fi też trzeba regularnie sprawdzać?

Tak.

Nie oznacza to, że każdy switch trzeba aktualizować co miesiąc.

Należy jednak znać:

• jego model,
• aktualną wersję firmware,
• status wsparcia producenta,
• dostępne aktualizacje,
• występujące podatności.

To samo dotyczy:

• access pointów,
• kontrolerów Wi-Fi,
• urządzeń storage,
• kontrolerów zarządzających serwerami.

Dojrzała infrastruktura to nie tylko aktualny Windows Server.

To całe środowisko.

Czy po aktualizacji praca inżyniera się kończy?

Nie.

Aktualizacja zakończona komunikatem:

„Success”

nie oznacza jeszcze, że środowisko działa prawidłowo.

Inżynier Lizard powinien po wykonaniu zmiany sprawdzić między innymi:

• dostępność urządzenia,
• działanie podstawowych usług,
• stan systemu,
• VPN,
• łączność sieciową,
• aplikacje,
• backup,
• logi,
• monitoring.

W przypadku systemu biznesowego warto również potwierdzić jego działanie z właścicielem aplikacji lub klientem.

Po zmianie środowisko powinno być jeszcze obserwowane.

Niektóre problemy ujawniają się dopiero po pewnym czasie.

Dlaczego aktualizacje trzeba dokumentować?

Ponieważ po kilku miesiącach nikt nie powinien polegać na pamięci administratora.

Dokumentacja powinna wskazywać:

• co zostało zaktualizowane,
• kiedy,
• z jakiej wersji,
• do jakiej wersji,
• kto wykonał zmianę,
• dlaczego została wykonana,
• czy wystąpiły problemy,
• jaki był rezultat.

Historia zmian ma ogromną wartość podczas późniejszego:

• rozwiązywania awarii,
• audytu,
• analizy bezpieczeństwa,
• planowania kolejnych upgrade’ów.

Czy Patch Management i Change Management to to samo?

Nie.

Patch Management dotyczy zarządzania poprawkami i aktualizacjami.

Change Management jest szerszym procesem zarządzania zmianami w środowisku IT.

Dobra aktualizacja powinna jednak być traktowana jako kontrolowana zmiana.

To oznacza:

• analizę,
• plan,
• akceptację,
• backup,
• wykonanie,
• test,
• dokumentację.

Dzięki temu ryzyko aktualizacji jest znacznie mniejsze.

Czy aktualizacje pomagają w NIS2 i KSC?

Regularne zarządzanie podatnościami, systemami i aktualizacjami jest jednym z fundamentów dojrzałego zarządzania cyberbezpieczeństwem.

Organizacja powinna wiedzieć:

• jakie posiada aktywa,
• jakie wersje systemów wykorzystuje,
• jakie podatności występują,
• które wymagają szybkiej reakcji,
• które systemy nie są już wspierane,
• jakie wyjątki zostały zaakceptowane.

Samo posiadanie firewalla, EDR czy backupu nie eliminuje ryzyka wynikającego z niezałatanych podatności.

Patch Management powinien więc być częścią szerszego procesu:

• zarządzania aktywami,
• zarządzania podatnościami,
• zarządzania ryzykiem,
• Change Management,
• bezpieczeństwa infrastruktury.

Co jest bardziej ryzykowne – aktualizowanie czy nieaktualizowanie?

Obie decyzje posiadają ryzyko.

Aktualizacja może spowodować:

• krótką przerwę,
• problem z kompatybilnością,
• potrzebę rollbacku,
• konieczność wykonania dodatkowych prac.

Brak aktualizacji może prowadzić do:

• pozostawienia znanej podatności,
• cyberataku,
• utraty danych,
• przejęcia serwera,
• przejęcia firewalla,
• utraty wsparcia producenta,
• coraz bardziej skomplikowanej przyszłej migracji.

Najważniejsza różnica polega na tym, że ryzyko planowanej aktualizacji można w dużym stopniu ograniczyć.

Służą temu:

• analiza,
• doświadczenie inżyniera,
• backup,
• test,
• właściwe okno serwisowe,
• plan rollbacku.

Ryzyko pozostawienia aktywnie wykorzystywanej podatności może być znacznie trudniejsze do kontrolowania.

Czy warto więc regularnie aktualizować serwery i urządzenia sieciowe?

Tak.

Ale nie należy robić tego bez planu.

Najlepsza odpowiedź brzmi:

regularnie analizować i aktualizować wtedy, kiedy jest to technicznie oraz biznesowo uzasadnione.

Inżynier Lizard może przeanalizować środowisko i zaproponować:

• które systemy wymagają aktualizacji,
• które aktualizacje są pilne,
• które można wykonać w standardowym cyklu,
• jak przygotować backup,
• kiedy przeprowadzić zmianę,
• jak ograniczyć wpływ na użytkowników,
• jak zweryfikować działanie systemu po aktualizacji.

Następnie doświadczony inżynier Lizard może wykonać zmianę w uzgodnionym terminie – w godzinach, kiedy klient nie pracuje, albo w ustalonym oknie serwisowym.

Przed wykonaniem zmiany zabezpieczy konfigurację lub zweryfikuje backup, wykona aktualizację, przeprowadzi testy i udokumentuje rezultat.

To jest zasadnicza różnica pomiędzy:

„kliknięciem aktualizacji”

a

profesjonalnym utrzymaniem infrastruktury IT.

Jak Lizard może zarządzać aktualizacjami infrastruktury?

Lizard może objąć procesem aktualizacji między innymi:

• Windows Server,
• Linux,
• środowiska wirtualizacyjne,
• firewalle,
• routery,
• switche,
• urządzenia Wi-Fi,
• systemy backupowe,
• urządzenia storage,
• inne elementy zarządzanej infrastruktury.

Proces może zostać dostosowany do środowiska klienta.

Dla jednego przedsiębiorstwa właściwe będzie miesięczne okno serwisowe.

Dla innego kwartalny przegląd części urządzeń oraz osobny proces aktualizacji krytycznych.

Dla środowiska produkcyjnego może być konieczne indywidualne planowanie każdej zmiany.

Najważniejsze jest to, aby infrastruktura posiadała właściciela oraz proces.

Klient powinien wiedzieć:

kto sprawdza aktualizacje, kto ocenia ryzyko, kto rekomenduje zmianę i kto odpowiada za jej bezpieczne wykonanie.

Taką rolę może pełnić inżynier Lizard.

15 pytań, które warto zadać działowi IT

1. Czy znamy wersje systemów na wszystkich serwerach?
2. Czy wiemy, jakie firmware działa na firewallach?
3. Czy monitorujemy wersje switchy i access pointów?
4. Czy wiemy, które urządzenia są już EOL?
5. Czy ktoś regularnie sprawdza nowe podatności?
6. Czy mamy określone terminy instalowania krytycznych poprawek?
7. Czy istnieją regularne okna serwisowe?
8. Czy przed aktualizacją wykonywany jest backup?
9. Czy konfiguracja urządzeń sieciowych jest archiwizowana?
10. Czy istnieje plan rollbacku?
11. Czy sprawdzamy dokumentację producenta przed upgrade’em?
12. Czy aktualizacje są wykonywane poza godzinami pracy użytkowników?
13. Czy po zmianie wykonywane są testy?
14. Czy aktualizacje są dokumentowane?
15. Czy zarząd wie, które systemy pozostają nieaktualne i dlaczego?

Jeżeli na kilka z tych pytań odpowiedź brzmi:

„nie wiem”

problemem prawdopodobnie nie jest tylko brak aktualizacji.

Problemem jest brak procesu zarządzania infrastrukturą.

Najczęściej zadawane pytania

Czy trzeba regularnie aktualizować serwery?

Tak. Serwery powinny być objęte regularnym procesem zarządzania aktualizacjami i podatnościami. Częstotliwość zależy od krytyczności systemu oraz rodzaju poprawek.

Czy każdą aktualizację trzeba instalować od razu?

Nie. Inżynier powinien przeanalizować jej znaczenie, ryzyko, ekspozycję systemu, zalecenia producenta i wpływ na środowisko.

Czy aktualizacja może zepsuć serwer?

Tak, dlatego profesjonalna aktualizacja powinna być poprzedzona analizą, backupem i planem rollbacku oraz wykonywana w kontrolowanym oknie serwisowym.

Czy warto aktualizować firewall, jeśli wszystko działa?

Tak. Firewall może działać poprawnie i jednocześnie posiadać znane podatności bezpieczeństwa.

Czy switche również trzeba aktualizować?

Tak, firmware switchy także powinien być monitorowany. Nie każda aktualizacja musi być wykonywana natychmiast, ale wersja systemu i status wsparcia urządzenia powinny być znane.

Czy najnowszy firmware zawsze jest najlepszy?

Nie. Inżynier powinien sprawdzić, która wersja jest rekomendowana przez producenta do środowisk produkcyjnych.

Co robi inżynier przed aktualizacją?

Powinien wykonać analizę, sprawdzić dokumentację producenta, ocenić ryzyko, zweryfikować backup, zabezpieczyć konfigurację i przygotować plan wycofania zmiany.

Kiedy najlepiej wykonywać aktualizacje?

W godzinach, w których klient nie pracuje, albo podczas wcześniej uzgodnionego okna serwisowego.

Co zrobić, jeśli systemu nie można zaktualizować?

Należy wykonać analizę ryzyka, zastosować odpowiednio zabezpieczenia kompensujące i przygotować plan migracji lub wymiany systemu.

Czy Lizard może zajmować się aktualizacjami serwerów i urządzeń sieciowych?

Tak. Inżynier Lizard może analizować potrzebę aktualizacji, rekomendować właściwe wersje i terminy, przygotowywać backup oraz plan rollbacku, a następnie wykonywać aktualizacje i weryfikować działanie infrastruktury po zmianie.