Podkast 23T10 ZTNA – Patch Enforcement

WERSJA TEKSTOWA

Cześć, witam Cię w moim odcinku podkastu, dzisiejszy temat to Enforcement Patch czyli management dla pathowania w połączeniu np. z rozwiązaniami NAC lub z rozwiązaniami VPN. O co chodzi? Chodzi o to, że chcemy mieć wymaganie dla stacji końcowej, żeby była cały czas na aktualnych łatkach. Czyli aby wszystkie podatności, które są znane były załatane na naszych stacjach końcowych zanim ta stacja będzie się mogła podłączyć czy do sieci korporacyjnej czy do sieci naszej zdalnie – czyli przez VPNa.

Jeżeli chodzi o implementację, to tutaj spotykam pierwsze pytanie – my mamy jakiś system dostarczenia Patchy i to tak naprawdę mogą być różne systemy. Np. Microsoftowy dla systemów Microsoft lub jakiś inny dla systemów trzecich. Tu też warto mieć na uwadze, że najczęściej dziurą jeśli chodzi o podatności jest sam system operacyjny ponieważ jest on pierwszym krokiem o którym wszyscy myślą gdy mówią o patchowaniu. Jest on najczęściej najbardziej wymagającym tematem. Łatanie aplikacji trzecich bo tych aplikacji może być mnóstwo mogą one być w różnych zestawieniach u różnych klientów i jak na tym wszystkim panować i jak to aktualizować jest ciekawym zagadnieniem natomiast zupełnie osobnym od dzisiejszego odcinka.

Dziś chciałem powiedzieć o możliwości w kontekście koncepcji Zero Trust Network Akcess, sprawdzania tego czy nasza polityka dotycząca pathowania jest zgodna, zanim podłączymy dane urządzenie. Czyli jeżeli chodzi o ZTMA najpierw sprawdzamy czy użytkownik ma uprawnienia czy jego stacja się nadaje i łączymy go tylko z aplikacjami do których powinien mieć dostęp. To są trzy najważniejsze rzeczy, jeśli chodzi o koncepcję Zero Trust Network Access i teraz to paczowanie jest jednym z elementów. Elementem, który jest związany z kontekstem stacji. Oczywiście chcielibyśmy też mieć możliwość zautomatyzowania procesu, że gdy użytkownik nie ma tego wymaganego patcha albo całej grupy, to automatycznie jakaś akcja, na razie tajemnicza, się wykona. Spowoduje ona, że wszystko zostanie spaczowane automatycznie i wtedy możemy tego użytkownika podłączyć do sieci.

Byłaby to idealna sytuacja i wdrożenie takiego procesu byłoby optymalnym rozwiązaniem pewnie dla każdej firmy i dla każdego administratora. Tak ja bym sobie życzył i życzę również tego wam. W praktyce jednak życie różnie się układa i często jest tak, że z różnych powodów stacja końcowa nie jest spathowana. Na przykład ktoś nie używał tego komputera przez miesiąc albo pół roku i teraz chciałby się podłączyć i chcemy sprawdzić czy on ma właściwe patche. Jeżeli nie to żeby sobie zainstalował zanim się podłączy do naszej sieci i to jest ten element który odróżnia to podejście klasyczne które do tej pory mieliśmy.

Klasyczne podejście mówiło: mamy system paczowania (już zakładam że mamy) i on po prostu działa. Nikt tego nie sprawdza, nikt tego nie weryfikuje, generalnie on działa a my mu wierzymy, że działa i wtedy jest wszystko elegancko. Mamy w raportach, że tutaj mamy pathowanie, tutaj wszystko działa, jest bezpieczne. W tej koncepcji Zero Trust Network Access my nie chcemy wierzyć, że coś działa, tylko my chcemy sprawdzać, że coś działa a jeżeli nie działa, to nie dawać dostępu albo dawać ten dostęp ograniczony i podnosić przy tej okazji akcję jakiejś remidiacji czyli jakiegoś naprawienia danej sytuacji. Jeżeli nie ma tego patcha to żeby po prostu ten patch mu zainstalować.

Używając systemów VPN czy NAC jeżeli używamy host checkera to mamy możliwość sprawdzenia pewnych rzeczy czyli mamy agenta na stacji końcowej i mówimy: Dobra to możemy sprawdzić czy dany poziom wymagany przez naszą organizację odnośnie łatek jest zainstalowany czy nie. Jeżeli nie, to albo nie dajemy dostępu, dajemy komunikat albo dajmy komunikat i mówimy: Za chwilę Ci to naprawimy. To by było najlepsze. Jeżeli jest naprawiony, jest zgodny to wtedy dopiero podłączamy. Tak byśmy chcieli to wykonać.

Nie jest to oczywiście proste bo musimy wyruszyć od punktu gdzie jesteśmy. Po pierwsze czy mamy system pathowania, czy mamy system w którym mamy wymuszanie – czyli VPNa albo NACa. Jeżeli mamy to czy my to sprawdzamy. Jeżeli sprawdzamy, to co zrobimy w momencie kiedy wykryjemy, że nie ma tego patcha i nie możemy niestety tej stacji podłączyć albo przynajmniej nie możemy z pełnym profilem podłączyć. Czy to ma być proces manualny, czy to ma być proces automatyczny…

Oczywiście ta gama pytań się pojawia naturalnie Natomiast jeżeli jesteśmy w stanie odpowiedzieć na te pytania w naszej konkretnej organizacji jak możemy to zrobić automatycznie, to to jest na pewno kierunek, który każdy by sobie życzył. Każdy z nas ma dużo pracy a nie potrzebuje dodatkowych zajęć. Z drugiej strony chciałbym ten poziom bezpieczeństwa dla organizacji dostarczyć wyższy. Wiadomo, że to jest w ogóle taki kierunek nie łatania różnego oprogramowania najbardziej ryzykowny. Jeśli ktoś ma znaną podatność i ona jest publiczna, to są gotowe narzędzia które potrafią tą podatność wykorzystać.

Więc tak ta sytuacja łączenia tego Patches Enforcement, czyli tego wymuszania pathowania z dostępem do naszej sieci – czy zdalnym czy lokalnym – możemy połączyć. Jak to zaimplementować – jeden z przykładów który teraz nad którym teraz pracuję z kolegami jest taki, żeby sprawdzał Host Checker daną informację od agenta pathowania i jeżeli widzi, że na przykład ten agent był aktywny, czy mógł sprawdzić (ale to było dłużej niż dzień temu albo tydzień temu), to żeby podjął jakąś akcję i ta akcja żeby wróciła do organizacji w postaci połączenia się z tym agentem i wymuszenia (czyli taki Trigger) aktualizacji dla tej stacji końcowej. Ta stacja oczywiście końcowa jest już umieszczona w systemie pathowania ma swoją politykę.

Chodzi o to, żeby sprawdzić czy ona faktycznie zadziałała czy zadziałała co najmniej w terminie, który my oczekujemy. Jeżeli nie to żeby z punktu widzenia VPN albo NACa wymusić tą aktualizację. Jest taka opcja, żeby to pathowanie wykonywać zarówno w formie podłączenia użytkownika w sieci korporacyjnej w jakimś ograniczonym profilu albo w sieci publicznej, czyli przez internet też jest taka możliwość. W zależności od systemu oczywiście pathowania ale jest taka możliwość, żeby wymusić tą akcję – dobrze to teraz zapaczuj tego konkretnego endpointa dlatego, że chcielibyśmy mieć aktualną informację, że on został zgodnie z polityką obsłużony. Wtedy możemy go właściwie podłączyć do naszej sieci niezależnie czy zdalnie czy lokalnie.

Takie są zagadnienia z ITNA i patch managementu, jeżeli to cię interesuje to oczywiście pisz w komentarzu. Jeśli jakieś inne tematy chciałbyś abym poruszył to oczywiście również jestem otwarty na wszelkie sugestie. Dziękuję za uwagę i do zobaczenia już za tydzień.