Tomasz Czoik: Na czym polega system Security Operation Center (SOC) stworzony przez firmę COIG?

Marek Ujejski, ekspert ds. cybersecurity z firmy COIG: System bazuje na zasadach ramowych opracowanych w USA. Jego podstawowym celem jest reagowanie w jak najkrótszym czasie na informacje o potencjalnych cyberzagrożeniach zbieranych z wszystkich możliwych źródeł – zarówno tych zbieranych automatycznie, jak i przekazywanych przez ludzi pracujących w monitorowanym środowisku. SOC stanowi więc coś na kształt centrum obrony przed cyberzagrożeniami.

Nieprzypadkowo koncepcja takiego centrum została ukształtowana i praktycznie wypróbowana w Siłach Powietrznych USA, gdzie dostrzeżono konieczność szybkiego reagowania na atak, podobnie jak ma to miejsce w obronie przeciwrakietowej i przeciwlotniczej. Wiele wniosły też doświadczenia Fire Brigade, amerykańskiej straży pożarnej, która w wypadku skomplikowanych wydarzeń losowych musiała potrafić wypracować w krótkim czasie właściwą ocenę sytuacji i następnie podjąć efektywne kroki.

Zadania Security Operation Center nie ograniczają się jednak wyłącznie do reagowania na konkretne zdarzenia?

– Oczywiście. Działania SOC obejmują też to, co moglibyśmy nazwać automatycznym audytem podatności istniejących w monitorowanych systemach, powtarzanym okresowo. Do realizacji tych zadań potrzebne są oczywiście odpowiednie narzędzia, które potrafią nie tylko zebrać informacje generowane w tych systemach, ale także ujednolicić je do pewnego wspólnego formatu, zapamiętać w odpowiednich bazach danych i – co najważniejsze – znaleźć korelacje pomiędzy informacjami znajdującymi się w tych logach. Trzeba bowiem mieć na uwadze, że w logach znajdują się nieraz dziesiątki milionów elementarnych informacji o tym, co się zdarzyło w poszczególnych systemach, i człowiek nie ma po prostu zdolności przeanalizowania ich wszystkich w krótkim czasie.

I tu z pomocą przychodzą narzędzia określane skrótem SIEM (System Incident and Event Management). To one właśnie dokonują analizy koincydencji zdarzeń opisanych w logach pochodzących z różnych systemów, a mających miejsce w tym samym lub zbliżonym czasie. Na tej podstawie system może generować alerty o podejrzanych zdarzeniach, nierzadko wymagających dodatkowej pracy personelu SOC, którego zadaniem jest ich obserwacja. Sposób reakcji na te alerty zależy w dużym stopniu od ustaleń zapisanych w umowach z klientem, może to być zarówno bezzwłoczne zablokowanie jakichś działań, dostępu do zagrożonych zasobów wykonywane samodzielnie przez oprogramowanie działające w SOC lub też przesłanie stosownej informacji do administratorów klienta ustaloną drogą komunikacji.

Trzeba mieć na uwadze, że teoretycznie najlepszy sposób reagowania, czyli odcięcie zasobów lub zatrzymanie procesów, może przynieść więcej szkody niż pożytku, szczególnie jeśli od funkcjonowania takiego procesu zależy krytycznie ważny proces.

Jak weryfikujecie, czy jakieś podejrzane zdarzenie nie wynika po prostu z pomyłki użytkownika?

– Wiele zdarzeń, np. nieudane logowania w nietypowej porze, wymaga dodatkowego wyjaśnienia poprzez kontakt z konkretnym, zidentyfikowanym użytkownikiem danego zasobu. Zdarza się, że zapomniał hasła, a miał do wykonania jakąś pilną pracę zleconą o nietypowej porze, niewynikającej z ustalonych zasad bądź z obserwacji jego typowego zachowania (czyli tzw. analizy behawioralnej).

Informacje o takich zdarzeniach są przekazywane do administratorów monitorowanego systemu, którzy z kolei wyjaśniają z użytkownikiem, czy to on rzeczywiście próbował się logować do systemu we wskazanych godzinach.

Z kolei próba np. kilkudziesięciokrotnego nieudanego logowania wskazuje raczej na próbę ataku lub brak właściwej konfiguracji oprogramowania działającego po stronie klienta. Takie przypadki też wymagają szczegółowego wyjaśnienia i trzeba im poświęcić więcej czasu, a czasem także wsparcia wspomnianej już drugiej linii składającej się z wysoko kwalifikowanych specjalistów.

Jeśli mówimy o automatyzacji działań, to zazwyczaj jest ona możliwa przy wsparciu systemu bardziej skomplikowanego niż omawiany wcześniej SIEM, a mianowicie SOAR (Security Orchestration and Automation Response). W używanym przez nasz SOC narzędziu o nazwie Secure Visio dysponujemy zarówno systemem SIEM, jak i SOAR, możemy więc zautomatyzować nasze działania tak daleko, jak to jest możliwe, oczywiście zgodnie z wolą klienta. Zanim jednak dojdzie do uruchomienia opisanej usługi, potrzebnych jest wiele uzgodnień z klientów, aby można było zbierać dane z systemów objętych monitoringiem.

Jednym z nich jest np. audyt wstępny?

– Tak, pozwala on ustalić aktualny stan bezpieczeństwa i dobrze rozpoznać źródła, jakimi są tzw. aktywne elementy systemu informatycznego (tzn. mające własny adres IP i zdolne do generowania choćby podstawowych informacji o swoim stanie). Bardzo często po tym audycie niezbędne jest zlikwidowanie odkrytych luk, ponieważ pozostawienie ich grozi skutecznym wykorzystaniem przez atakującego.

Nie odmawiamy jednak monitorowania „dziurawych" systemów, a nasze narzędzie w bazie danych zapisuje informacje o odkrytych podatnościach, co pozwala na skuteczniejszą analizę zdarzenia, gdyby w późniejszym okresie ta luka została wykorzystana przez atakującego.

Niejako równolegle do pracy SOC uruchamiany jest okresowo skan automatyczny chronionej infrastruktury, który wykrywa nowe bądź niedawno ujawnione podatności. Narzędzie to, zwane ogólnie SST (Security Scanner Tools), to narzędzie, które na podstawie wbudowanych reguł i na bieżąco aktualizowanej bazy wiedzy o podatnościach, tworzone przez organizacje o światowej wiarygodności, wykrywa aktualne zagrożenia i tworzy wpis o ich istnieniu do bazy działającej w narzędziu wspierającym SOC.

Cykliczne wykonywanie tej czynności, najczęściej raz na tydzień (trzeba mieć bowiem na względzie, że jest to czynność obciążająca monitorowany system), pozwala na gromadzenie pełnej wiedzy o wspomnianych już „dziurach" w systemach i odpowiednie reagowanie w sytuacjach podejrzanych. Nie jest to koniec możliwości działania SOC – przez odpowiednią analizę procesów podmiotu, wykorzystując też narzędzia do tworzenia aktualnej ciągle tzw. mapy logicznej systemu informatycznego który chronimy, można informować także kierownictwo o zagrożeniu procesów biznesowych, których działanie zależy od zidentyfikowanych komponentów infrastruktury informatycznej.

Do jakich firm skierowane są rozwiązania tego typu SOC?

– W zasadzie do każdej. Oczywiście nie mówimy tu o jednoosobowych mikrofirmach, zawsze trzeba rozważyć opłacalność ekonomiczną takiego rozwiązania. Ale gdyby taki klient zwrócił się do nas, to mógłby liczyć na konsultacje w zakresie bezpieczeństwa za akceptowalną dla obu stron kwotę. Co ważne, rozwiązania klasy SOC pozwalają spełnić wymogi wynikające z ustawy o krajowym systemie cyberbezpieczeństwa w kontekście instytucji świadczących tzw. usługi kluczowe, czyli mówiąc wprost – zapewniających spełnienie najistotniejszych potrzeb społeczeństwa. Takimi usługami są na przykład dostawy wody, wytwarzanie i dostawy energii elektrycznej czy też niektóre usługi zdrowotne. Istotą tych usług jest ich zależność od systemów informatycznych, bez których nie mogłyby działać bądź ich jakość byłaby poważnie obniżona.

Ustawa wymaga, aby systemy informatyczne, od których zależy świadczenie usług kluczowych, były monitorowane. Można więc powiedzieć, że instytucje te muszą posiadać własny system SOC lub też skorzystać z usługi zewnętrznej firmy świadczącej tzw. usługi cyberbezpieczeństwa, na to bowiem zezwala ustawa.