fbpx

Podkast 22T18 Okta, SOC, incydenty bezpieczeństwa

Więcej miejsc do posłuchania:

Spotify

WERSJA TEKSTOWA

Cześć, witam Cię w dzisiejszym odcinku mojego podkastu. Temat to zespoły SOC w mniejszych firmach. Ostatnio miałem ciekawe przemyślenie patrząc na nowoczesne narzędzia dotyczące zdalnego dostępu. To, co wiedzę, że się pojawia jako główny, popularny problem u wielu klientów, to jest właśnie sytuacja za dużej ilości zadań, zwłaszcza w kontekście bezpieczeństwa i poszukiwanie narzędzi, sposobów działania, które umożliwią zwiększenie efektywności. Przykładowo, aby można było sprawdzać właściwe zdarzenia bezpieczeństwa w ramach takiego zespołu SOC lub po prostu administratora, jeśli takiego zespołu nie ma.

Dla tych, którzy nie wiedzą co to jest zespół SOC – Security Operations Center, czyli takie miejsce, gdzie analizujemy różne zgłoszenia bezpieczeństwa. Przykład, który miałem ostatnio: Dostałem maila z systemu Okta. Jest to system uwierzytelniania dwuskładnikowego, gdzie można sobie założyć konto i dodatkowo w swojej organizacji uwierzytelniać dostęp. Wszystko było doskonale, tyle tylko, że ja nie prosiłem o reset hasła a dostałem taki mail. Takie zdarzenie jest to sytuacja, w której typowo powinno się przeanalizować dane zdarzenie – co się stało, jaki był powód, że został wysłany taki request, czyli prośba o reset hasła. W tym przypadku, który ja doświadczyłem nie było to zagrożenie bezpośrednie, związane z moją aktywnością. Natomiast było to związane z podatnością, czy z takim incydentem bezpieczeństwa, który został zarejestrowany po stronie systemu Okta i w związku z tym wysłano automatyczne maile o reset haseł do klientów, którzy byli zidentyfikowani jako potencjalnie narażeni w tym okresie, w którym ten incydent zadziałał.

O co chodziło w tym incydencie? Chodziło o to, że jeden z kontraktorów, czyli z firm podwykonawczych a konkretnie inżynier supportowy, który obsługiwał zdarzenia czy zgłoszenia supportowe do tego systemu. Zarejestrowano, że miał zainstalowany software, który powodował przechwycenie uprawnień jego stacji. W związku z tym ten pracownik mógł mieć dostęp do pewnych klientów, którzy byli w tym czasie obsługiwani przez tą firmę podwykonawczą. Jako element zaradczy wysłano taką ilość maili, dotyczących zmian haseł dla użytkowników. Ja takiego maila dostałem. Jeśli mamy taki zespół operacyjny to powinien się on zainteresować co takiego się wydarzyło, że takie zdarzenie miało miejsce. Może to być zwykła pomyłka, może to być celowe działanie, ale bez dodatkowych zagrożeń, uprawnień dla takiej osoby. W przypadku gdy ktoś zna maila i wie, że dana osoba ma dostęp do danego systemu, może wejść na publiczny system i wygenerować taki request.

Natomiast jest to już zdarzenie, które może sugerować jakieś zdarzenia i warto się przyglądać takim sytuacjom. Temu właśnie ma służyć taki zespół SOC, który sprawdza poszczególne incydenty i weryfikuje, czy są one groźne, istotne, czy nieistotne. Jeśli chodzi o mniejszych klientów, to w zasadzie tu takiej możliwości nie ma, bo ilość tych zagrożeń, które są dziś i potencjalnych zgłoszeń, jest tak duża, że jeden administrator utrzymujący jeszcze dany system, nie jest w stanie tego robić. W związku z tym opcje są dwie. Albo dana firma może rozważyć outsourcing takiego zestawu kompetencji, czy takiego centrum bezpieczeństwa, albo może szukać narzędzi, które pomogą w analizie. Np. zmniejszą ilość zgłoszeń do jakiś naprawdę istotnych, naprawdę rokujących tutaj duże zagrożenie.

Jeżeli wybierzemy trzecią opcję, która zawsze jest możliwa – nie robić nic, to na bieżąco, jak wielu z nas działa, jest tak, że robimy co możemy a resztę zwyczajnie ignorujemy i czas pokaże, czy to było istotne. Niestety ten trzeci przypadek ma duży minus – jak już się coś zadzieje to w zasadzie jesteśmy z ręką w nocniku i niewiele możemy zrobić. Oprócz tego, że powinniśmy prześledzić daną historię zdarzenia. Co jest też z kolei problemem, bo śledząc wspomniany przypadek Okty, byli w stanie z dokładnością w zasadzie co do minuty, określić jakie postępowanie było podjęte, w którym momencie dowiedzieli się o zdarzeniu, w którym momencie został zablokowany dostęp czy ograniczenie zasięgu tego incydentu bezpieczeństwa. Tego typu funkcjonalność, takie działanie, powinno być dobrą praktyką dla wszystkich. Niestety małe firmy, jeśli nie mają dedykowanej osoby, już nie mówiąc o dziale, dotyczącego bezpieczeństwa, to siłą rzeczy nie są w stanie tego łatwo monitorować. Ewentualnie w przypadku, gdy są lepiej zorganizowane, to mogą sobie pewne rzeczy logować i wynająć firmę dotyczącą analizy zdarzeń. Takie sytuacje też widziałem, gdzie firma trzecia bazując na dostarczonych danych z różnych systemów, np. z firmowych, jest w stanie przeprowadzić analizę i przedstawić wnioski.

Jest to też istotne w kontekście obowiązującego prawa, czyli jeśli nastąpił wyciek danych, takie włamanie, to powinniśmy szczegółowo przedstawić informacje, które tego dotyczą i osoby, które są wiązane z tym wyciekiem. W związku z tym motywuje nas też to, że jest regulacja prawna w tym zakresie. Jeśli chodzi o narzędzia to, jeśli mamy jakiś system User Behaviour Analytics (UBA) to mamy już jakieś wskazania dotyczące tego, gdzie powinniśmy się przyglądać. Którzy użytkownicy zachowują się dziwnie, widzimy jakieś anomalie, odstępstwa od typowych profili zachowań. To są też m.in. wskaźniki, gdzie taka osoba czy taki zespół powinien się przyglądać, do których zdarzeń, powinien zaglądać.

Z drugiej strony, jeśli popatrzymy sobie na mniejsze firmy, gdzie jest mniej użytkowników, to też powinno być mniej tych zdarzeń. W zależności od tego jaka jest proporcja administratorów, osób od bezpieczeństwa do ilości użytkowników, taką sytuację będziemy mieli. To co widzę, to pojawiające się nowe narzędzie, głównie cloudowe, które umożliwiają nam wykupienie usługi i dzięki temu łatwo skorzystanie z takiego monitoringu, z takiego scoringu i ewentualnie blokowania automatycznego, też możemy tego typu zachowania konfigurować, że przy danym scenariuszu możemy zablokować dostęp i do czasu wyjaśnienia sytuacji dany użytkownik ma ograniczony dostęp albo do pewnych zasobów, albo całkowicie do sieci.

Mam nadzieję, że to było dla Ciebie ciekawe, dziękuję Ci za dzisiaj, za uwagę i do usłyszenia już za tydzień.


Kurs NAP MT Basic - Chcesz poznać podstawy konfiguracji routera MikroTik? Przedsprzedaż tylko do 20.05.2022 '(piątek)' do 21:00

Autor: Darek Koralewski

Od początku swojej kariery, czyli od 2004 roku, zajmuję się sieciami komputerowymi ze szczególnym uwzględnieniem ich bezpieczeństwa oraz sieciami programowalnymi. Mam na swoim koncie całą listę certyfikatów różnych producentów, dwa najważniejsze to te poświadczające najwyższy poziom wiedzy eksperckiej z zakresu rozwiązań Aruba ClearPass ACCX#901 oraz z projektowania sieci opartych o rozwiązania Aruba ACDX#1255. Więcej informacji możesz znaleźć na moich portalach społecznościowych.