Dylemat administratora - aktualizować czy nie aktualizować?

Dylemat administratora – aktualizować czy nie aktualizować?

Zagadnienie aktualizacji czy „łatania” systemów jest w biznesie problemem, który wymaga odpowiedniego podejścia, często określanego mianem zarządzania lub strategii wprowadzania poprawek. Jest to temat o tyle zawiły, że z punktu widzenia bezpieczeństwa, wymagane jest utrzymywanie bezpiecznych systemów, z rekomendowaną przez producenta wersją oprogramowania, przy jednoczesnym zorientowaniu na potrzeby biznesu, które wymagają zapewnienia ciągłości i stabilności działania. W tym miejscu popularnym jest stwierdzenie, że jak coś działa to nie należy tego ruszać, bo się popsuje. W istocie, niejednokrotnie przekonałem się na własnej skórze, że wykonanie aktualizacji systemu do wyższej wersji oprogramowania, celem zaadresowania wykrytych błędów i podatności, kończyło się historią, gdzie nagle patchowany system napotykał problem w trakcie aktualizacji i należało robić „szybki rollback” albo kosztem poprawionych błędów odkrywało się, że w przypadku tej specyficznej konfiguracji systemu jakaś funkcja po aktualizacji przestaje działać prawidłowo i zaczyna się etap rozwiązywania tego zjawiska, niejednokrotnie kończący się również powrotem do działającej stabilnie wersji. Oczywiście, wokół tego dochodziła cała otoczka związana z planowaniem okna serwisowego, w trakcie którego system musiał być niedostępny dla użytkowników końcowych, przygotowaniem odpowiedniej komunikacji, a także zabezpieczeniem możliwości wspomnianego już powrotu do starszej wersji poprzez wykonanie kilku kopii zapasowych konfiguracji – tak na wszelki wypadek. Czas to pieniądz, a przestoje w pracy spowodowane niedostępnością systemów umożliwiających realizowanie zadań biznesowy sprawiają, że biznes nie zarabia pieniędzy.

Jak więc pogodzić kwestie bezpieczeństwa z oczekiwaniami biznesu?

Zacznę od samej kwestii, dlaczego łatanie systemów jest tak istotne. Poza aspektem rozwojowym dla utrzymywanych systemów, czyli wprowadzaniu nowych funkcji, zwiększeniu stabilności lub poprawie błędów w działaniu oprogramowania, najbardziej krytyczne dla usprawiedliwienia konieczności patchowania jest istnienie podatności. Są to luki lub słabe punkty w kodzie systemu/aplikacji, powstałe w wyniku błędu projektowego lub implementacyjnego, które umożliwiają wykonanie szkodliwych działań w ramach danego oprogramowania. Nie istnieje jedno uniwersalne remedium na podatności. Są to rzeczy, które istniały i istnieć będą zawsze. Podatności nie są też znane od razu po opublikowaniu systemu, a dopiero w cyklu życia oprogramowania są sukcesywnie ujawniane i producenci odpowiadają na odkryte luki w postaci łatek poprawiających wadliwy kod. Odkryte podatności otrzymują ocenę w zależności od tego jak ich wykorzystanie może być niebezpieczne dla działania oprogramowania. Za ocenę tą odpowiada CVSS (Common Vulnerability Scoring System). Podatność może zostać oceniona w skali od 0 do 10, gdzie 0 oznacza niski poziom niebezpieczeństwa, a 10 wskazuje na krytyczną podatność, która powinna zostać poprawiona jak najszybciej.

Skoro wiadomo już, dlaczego łatanie systemów jest takie ważne i czym są podatności, to kolejnym aspektem jest określenie co należy rozumieć przez stwierdzenie by poprawiać podatności „jak najszybciej”. Niestety, w rzeczywistości to nie oznacza, że chwilę po opublikowaniu istniejącej podatności, za sprawą kilku „kliknięć” zabezpieczymy system. Najczęściej jest to proces, który potrafi trwać od kilku do kilkunastu tygodni. Na cały proces składa się kilka etapów:

1. Przygotowanie poprawki przez producenta
2. Przetestowanie poprawki przez producenta
3. Opublikowanie poprawki przez producenta
4. Zaplanowanie okna serwisowego przez administratora systemu
5. Wykonanie instalacji poprawki na podatnym systemie
6. Testy poprawności działania systemu po instalacji poprawki

Każdy z tych etapów alokuje pewną ilość czasu, w którym nasz system pozostaje podatny i możliwy do eksploitacji, czyli właśnie wykorzystania luki do spenetrowania systemu. Znakomita większość tego czasu to okres bezczynności administratora, który jedyne co może robić to czekać, aż producent opublikuje poprawkę dla odkrytej podatności. Różne badania firm pokazują, że czas potrzebny na aktualizację systemów w organizacji to średnio między 60 a 150 dni. Jako przykład, o którym było głośno w roku 2017, może posłużyć sytuacja związana z ransomware (rodzaj złośliwego oprogramowania, który szyfruje dane na stacji końcowej, a następnie przestawia żądanie okupu w kryptowalucie, np. bitcoin, w zamian za udostępnienie klucza do dekrypcji danych) o nazwie WannaCry. WannaCry lub WCRY wykorzystywał podatność w systemach Microsoft Windows (MS17-010 – „Eternalblue”) dotyczącą protokołu SMB (Server Message Block) w celu zainfekowania ich, a następnie umożliwiając ransomware rozprzestrzenienie się w obrębie całej sieci na inne znajdujące się w niej komputery, szyfrując dane znajdujące się na nich. Przyglądając się osi czasu dotyczącej tej konkretnej podatności, widać doskonale jak wyglądał proces jej adresowania przez producenta jak i administratorów systemów. Istnienie podatności zostało ogłoszone przez amerykańską instytucję CERT (Computer Emergency Response Team) w dniu 16 stycznia. Microsoft opublikował łatkę naprawiającą lukę na wspieranych systemach operacyjnych w dniu 14 marca (Windows XP był już na liście systemów niewspieranych, poprawka dla tego systemu została wydana dopiero 12 maja). W tym okresie podatność ta była znana i możliwa do wykorzystania przez atakujących. Faktycznie, kampania ataków za pomocą ransomware WannaCry została uruchomiona dopiero 12 maja. Szacuje się, że zainfekowanych zostało około 230000 komputerów w 150 krajach tylko tego jednego dnia. Idąc dalej tropem podatności i niebezpieczeństw jakie są z tym związane, wg raportu instytutu ponemon z roku 2019, 60% ofiar włamań stwierdziło, że stało się tak ponieważ atak wykorzystywał znane podatności w systemach, które nie zostały załatane. Jak więc jest z tymi aktualizacjami w organizacjach?

Virtual Patching

W tym miejscu dochodzę do aspektu biznesowego. Jak już wcześniej wspominałem biznes przede wszystkim patrzy na kwestie zarabiania pieniędzy, w związku z tym krytyczne systemy muszą cechować się jak najdłuższą i nieprzerwaną pracą, ponieważ każdy przestój w ich działaniu oznacza jednocześnie przerwę w świadczeniu usług, a co za tym idzie zatrzymuje zarabianie pieniędzy. Administratorzy bezpieczeństwa są w związku z tym stawiani w bardzo trudnej sytuacji, w której po jednej stronie mają kwestie bezpieczeństwa i narażania organizacji na potencjalne ataki hackerskie, a z drugiej strony ciągłość funkcjonowania usług krytycznych często dla całości biznesu. Zaplanowane okna serwisowe, problemy jakie mogą się pojawić w związku z niestabilnością systemów lub wręcz ryzyko, że coś pójdzie nie tak w trakcie aktualizacji dla niektórych firm lub instytucji mogą być równoznaczne z niedostępnością usług spowodowaną atakiem hackerskim. Prawdziwym wyzwaniem staje się w takich sytuacjach znalezienie złotego środka. Rozwiązaniem jakie osobiście w takich sytuacjach przetestowałem i sugeruję jest tak zwany Virtual Patching. Jest to funkcjonalność, dość unikatowa w swojej klasie, którą w swoim portfolio posiada rozwiązanie Deep Security od Trend Micro.

Rozwiązanie Deep Security

Trend Micro Deep Security jest rozwiązaniem do ochrony systemów fizycznych, wirtualnych, chmurowych oraz kontenerowych. Wspiera ono platformy takie jak: Microsoft Windows, Red Hat Enterprise Linux, CentOS, Oracle, SUSE, Ubuntu, Debian, Solaris, Amazon, a także środowiska wirtualne w ramach platformy NSX. Udostępnia ono zestaw narzędzi, dzięki którym można zabezpieczyć swoje systemy na wielu płaszczyznach. W ramach ochrony Deep Security otrzymujemy moduły ochrony takie jak:

• Ochrona przed intruzami
• Anty Malware
• Firewall
• Reputacja webowa
• Monitoring integralności
• Inspekcja logów
• Kontrola aplikacji

Z perspektywy ochrony przed podatnościami, najbardziej interesującym modułem będzie ten dotyczący ochrony przed intruzami. Moduł ten umożliwia inspekcję całego przychodzącego i wychodzącego ruchu w celu wykrycia i zablokowania podejrzanej aktywności. Chroni to przed eksploitacją systemów za pomocą znanych podatności, jak również tak zwanych podatności dnia zerowego (zero-day vulnerabilities) czyli nie znanych jeszcze producentom danego oprogramowania czy systemu. W tym miejscu pojawia się wątpliwość, ponieważ skoro nikt nie wie o podatnościach dnia zerowego, to jak system typu Deep Security może zapewniać przed nimi ochronę. Odpowiedzią na to jest prowadzona przez Trend Micro inicjatywa dnia zero (Zero Day Initiative – ZDI). Co się za tym kryje? W ramach ZDI firma Trend Micro prowadzi bazę danych podatności w różnego rodzaju systemach i aplikacjach. Każdy może wysłać zgłoszenie o odkrytej przez siebie podatności do Trend Micro, które następnie ta firma weryfikuje i jeżeli potwierdzi, że faktycznie ta podatność istnieje i nie jest załatana, nagradza osobę zgłaszającą, a następnie informuje producenta o odkryciu podatności w jego systemie oraz opracowuje własną łatkę, która następnie pojawia się do wykorzystania w systemie Deep Security. Co daje zastosowanie tego typu „wirtualnej łatki”? Przede wszystkim oszczędza czas. Dla zabezpieczenia systemu przed wykrytą podatnością nie jest wymagane okno serwisowe, a implementacja ochrony jest możliwa do zastosowania w bardzo krótkim czasie, zależnym od tego, jak szybko nowa reguła bezpieczeństwa zostanie rozpropagowana do chronionych systemów. Idąc dalej, daje nam to ochronę nim producent opracuje poprawkę do swojego systemu i zanim administratorowi uda się tą łatkę zainstalować we wcześniej zaplanowanym oknie serwisowym. Wypełnia to dziurę w procesie, która normalnie istnieje w czasie pomiędzy odkryciem podatności, a jej poprawieniu w formie łatki. Szacuje się, że średni czas nim system zostanie załatany przed wykrytą podatnością to od 60 do nawet 150 dni. Czy w związku z tym funkcja Virtual Patching sprawia, że podatność przestaje istnieć i możemy zapomnieć o aktualizowaniu systemów? Nie. Po pierwsze, mimo zaadresowania podatności przez Deep Security, ona nadal istnieje w niezałatanym systemie. Deep Security zapewnia tylko (i aż!) ochronę przed wykorzystaniem tej podatności na poziomie warstwy sieciowej. Po drugie, za sprawą aktualizacji ze strony producentów często idą również nowe funkcje i inne dodatkowe poprawki mniej krytycznych błędów.