Incydent (wg. ustawy KSC) to zdarzenie, które ma lub może mieć niekorzystny wpływ na cyberbezpieczeństwo rozumiane jako odporność systemów informacyjnych na działania naruszające poufność, integralność, dostępność i autentyczność przetwarzanych danych lub związanych z nimi usług oferowanych przez te systemy. Wczesna identyfikacja zagrożeń pozwala niejednokrotnie zapobiec incydentom poprzez wdrożenie środków zaradczych np. polegających na ograniczeniu uprawnień, modyfikacji reguł zapory sieciowej, zainstalowaniu aktualizacji systemów. Misja SOC nie ogranicza się zatem do reagowania na incydent w momencie jego wystąpienia; ona obejmuje także zapobieganie incydentom i to ta aktywność przynosi największe, choć niedoceniane, korzyści.
Do realizacji misji, SOC potrzebuje wiedzy na temat chronionej infrastruktury oraz zestawu narzędzi i procedur dających nie tylko wgląd w funkcjonowanie systemów IT, lecz także umożliwiających skuteczne reagowanie na występujące anomalie czy inne zdarzenia naruszające bezpieczeństwo.
Adresowanie zagrożeń wymaga ścisłej współpracy pomiędzy administratorami systemów, właścicielami zasobów (assetów) i specjalistami bezpieczeństwa. Działania te muszą być realizowane zgodnie z procedurami określonymi m.in. w Systemie Zarządzania Bezpieczeństwem Informacji. Procedury i SZBI muszą natomiast czynić zadość obowiązującym legislacjom.
Możliwości reakcji warunkują zakres odpowiedzialności zespołu SOC w przypadku wystąpienia incydentu. Określenie zakresu odpowiedzialności i zasad reagowania jest szczególnie istotne, jeżeli realizacja zadań SOC jest zlecana podmiotom zewnętrznym (outsourcing) w stosunku do chronionej organizacji.
Czy SOC jest wymagany prawem?
W przepisach prawa (KSC, NIS2) nie ma literalnie wpisanej potrzeby utworzenia SOC w organizacjach czy wykupienia zarządzanych usług bezpieczeństwa typu SOC, ale są wymagania proceduralne, które odpowiadają w dużej mierze zakresowi działania typowych SOC-ów. Warto tu wymienić następujące wymagania pojawiające się w istniejących i planowanych ustawach w kontekście podmiotów objętych Krajowym Systemem Cyberbezpieczeństwa:
- wymóg monitoringu systemów informacyjnych pod kątem ich bezpieczeństwa w trybie ciągłym,
- niezwłoczne podejmowanie działań po dostrzeżeniu podatności lub cyberzagrożeń,
- obsługa incydentów oraz przekazywanie informacji o incydentach w ścisłym reżimie czasowym.
Modele funkcjonowania SOC
Kluczowe wymaganie dla SOC to działanie w trybie ciągłym (24/7/365). Aktualnie przyjmuje się takie funkcjonowanie jako standard, inne tryby funkcjonowania stają się rzadkością (np. tylko w godzinach biznesowych). Modele funkcjonowania SOC dzieli się głównie pod kątem umiejscowienia zespołów.
Pierwszy rodzaj SOC, to SOC wewnętrzny – członkowie zespołu specjalistów są zatrudnieni bezpośrednio przez organizację, którą chronią. W praktyce, oznacza to konieczność zatrudnienia co najmniej 5-7 specjalistów (w tym część osób w niepełnym wymiarze). W tym modelu większość narzędzi osadzonych jest w infrastrukturze chronionej organizacji (np. SIEM czy kolektor logów), przy czym część narzędzi (np. konsola EDR czy XDR) może być osadzonych w środowisku chmurowym i udostępnianych zespołowi w modelu software as a service (SaaS), jako zarządzana usługa bezpieczeństwa. Niewątpliwym plusem SOC wewnętrznego jest możliwość pełnej integracji ze strukturami wewnętrznymi organizacji, co ułatwia reagowanie na incydenty i identyfikację zagrożeń – taki zespół SOC może mieć bezpośrednią kontrolę nad kluczowymi urządzeniami w wewnętrznej infrastrukturze organizacji oraz bezpośredni wpływ na administratorów. Minusem są wysokie koszty, które mogą być nieadekwatne do wielkości organizacji.
Koszty i brak wystarczającej liczby odpowiednio wyszkolonych pracowników to główne powody pojawienia się innych modeli funkcjonowania zespołów SOC, w szczególności SOC zarządzanego (Managed SOC), czy też SOC jako usługa (SOCaaS). W obydwóch przypadkach usługi są delegowane – bezpieczeństwo monitorują osoby z zewnętrznej firmy. Przy czym w przypadku Managed SOC część kluczowych systemów bezpieczeństwa może być posadowiona w infrastrukturze chronionej organizacji lub w chmurze; zakres usług może być tu szerszy niż w przypadku SOCaaS. W SOCaaS większość narzędzi wykorzystywanych przez SOC jest posadowiona w infrastrukturze usługodawcy, w szczególności w chmurze. Zespół usługodawcy koncentruje się na identyfikowaniu zagrożeń, w tym analizie ryzyka i szybkim reagowaniu. Natomiast Managed SOC, w odróżnieniu od SOCaaS, może bardziej kompleksowo zarządzać systemami bezpieczeństwa organizacji oraz wspierać audyty wewnętrzne czy wymogi legislacyjne.
Dodatkowo, popularność zdobywa usługa MDR, która koncentruje się na wykrywaniu zagrożeń w oparciu o systemy EDR oraz analizy ruchu sieciowego (NTA), a także realizuje pewne zaawansowane elementy, tzw. threat-huntingu (m.in. identyfikacji nowych zagrożeń). Narzędzia SOC omówione zostaną w kolejnej sekcji.
Ostatnim najczęściej wymienianym modelem SOC, jest model hybrydowy. W tym przypadku organizacja ma wewnętrzny silny zespół SOC i zleca tylko wybrane elementy na zewnątrz, np. korzysta z narzędzi w modelu chmurowym lub zleca konkretne zadania kontrahentom zewnętrznym (np. skanowanie systemów publicznie dostępnych czy analizy powłamaniowe). W tym modelu organizacja ma zwykle pełną kontrolę nad krytycznymi funkcjami zabezpieczeń.
Przyjrzyjmy się narzędziom wykorzystywanym w SOC-ach.
Narzędzia SOC
Celem tej sekcji jest wskazanie typów narzędzi, którymi posiłkują się zespoły bezpieczeństwa, aby chronić infrastrukturę.
Rejestrowanie występujących zdarzeń i podejmowanych aktywności związanych z incydentami jest niezbędne do zapewnienia należytego poziomu usług. Do tego celu wykorzystuje się różnej maści system obsługi zgłoszeń (np. JIRA, Zammad, RT, RTIR itp.).
Zgłoszenia zdarzeń mogą pochodzić od użytkowników, podmiotów zewnętrznych, analityków lub z wdrożonych systemów bezpieczeństwa, np. zapór sieciowych czy analizatorów logów.
Zapory sieciowe pełnią dwojaką rolę – mogą sygnalizować zagrożenia z wykorzystaniem zdefiniowanych reguł oraz mogą być wykorzystywane do reagowania na incydenty poprzez blokowanie lub ograniczanie ruchu sieciowego. Firewalle najnowszych generacji mają dość rozbudowane mechanizmy detekcji zagrożeń i reagowania.
Kompleksowa analiza logów systemów jest możliwa tylko jeśli logi są zebrane w jednym miejscu. Do zbierania logów wykorzystuje się kolektory logów. W przypadku zdarzeń bezpieczeństwa najczęściej wykorzystuje się tzw. systemy SIEM (Security Information and Event Management), które koncentrują się na analizie informacji ukierunkowanych na bezpieczeństwo. Systemy SIEM umożliwiają korelację zdarzeń, analizy statystyczne, wykrywanie anomalii oraz wysyłanie powiadomień (alert), np. w przypadku wykrycia nieprawidłowości lub podejrzanych aktywności.
Kluczowe znaczenie w identyfikacji zagrożeń ma nie tylko analiza logów z systemów operacyjnych czy aplikacji, ale także wgląd w ruch sieciowy. Ruch sieciowy analizuje się zwykle z wykorzystaniem kolektorów rekordów przepływów (Netflow czy IPFIX) oraz systemów detekcji intruzów (IDS), tj. sensorów umieszczonych w chronionej infrastrukturze. Wyniki analizy rekordów przepływów mogą stanowić dodatkowe źródło informacji przekazywanych do SIEM.
Organizacja, która ma wdrożony i dostrojony system SIEM może dodatkowo wdrożyć system SOAR (Security Orchestration, Automation, and Response) w celu automatyzacji i orkiestracji procesów reagowania. Automatyczne reagowanie może również objąć stacje końcowe, ale do tego służy kolejny rodzaj systemu ochrony – system EDR.
Systemy EDR (Endpoint Detection and Response) dbają o ochronę punktów końcowych w sieci poprzez wykrywanie i reagowanie na podejrzane aktywności związane ze złośliwym oprogramowaniem, ransomware czy innymi typami ataków. Kluczowe jest tu reagowanie bezpośrednio na chronionych stacjach, serwerach, urządzeniach mobilnych. EDR w ramach reakcji może np. blokować procesy lub izolować zagrożone punkty końcowe. Informacje ze stacji końcowych przekazywane są do centralnej konsoli zarządzania.
Systemy XDR (eXtended Detection and Response) niejako rozszerzają funkcjonalność systemów EDR poprzez uwzględnienie aktywności sieciowej, systemów chmurowych, systemów poczty elektronicznej, a także zastosowanie zaawansowanych algorytmów analitycznych w celu identyfikacji i priorytetyzacji zagrożeń. Systemy XDR mogą podejmować automatyczne akcje zarówno na urządzeniach końcowych (jak to ma miejsce w przypadku EDR), jak i w warstwie sieciowej czy infrastrukturze serwerowej, z której urządzenia końcowe korzystają.
Monitoring dostępności zasobów to kolejny element wspomagający cyberbezpieczeństwo i identyfikację incydentów. Podobnie jak zespoły NOC (Network Operation Center), monitorujące dostępność sieci, czy administratorzy systemów, także zespoły bezpieczeństwa posiłkują się systemami monitorującymi funkcjonowanie usług w tym czasów odpowiedzi. Do tego celu wykorzystuje się m.in.: Zabbix, SolarWinds, Nagios.
Skuteczne adresowanie zagrożeń wymaga wiedzy o wersjach zainstalowanych w organizacji aplikacji oraz dotyczących ich znanych podatności na ataki, a także eksploitów aktualnie wykorzystywanych przez adwersarzy. Do tego celu wykorzystuje się systemy zarządzania podatnościami, w tym systemy inwentaryzacji zasobów.
Zestaw najpopularniejszych narzędzi zamykają systemy do wymiany informacji o zagrożeniach, takie jak: MISP czy OpenCTI, które wspomagają budowanie szerszej świadomości sytuacyjnej.
Dodatkowo warto wspomnieć jeszcze o narzędziach do analiz powłamaniowych oraz zabezpieczania dowodów, np. narzędziach do tworzenia zrzutów pamięci oraz obrazów dysków. Narzędzia te wykorzystywane są, gdy inne zabezpieczenia zawiodły i doszło do naruszenia bezpieczeństwa.
Elementy proceduralno-prawne
Bardzo istotnym elementem funkcjonowania SOC są procedury, które określają zasady przetwarzania danych i postępowania.
Dla znanych typów incydentów, problemów czy ataków definiuje się zwykle tzw. playbooki – czyli instrukcje postępowania zapewniające skuteczne i co ważne spójne reagowanie.
Przetwarzanie danych, ograniczanie dostępu do danych, blokowanie ruchu nie może mieć miejsca, jeśli tych działań nie określono w stosownych umowach (m.in. NDA).
Ważne jest też określenie sposobu oceny działań SOC, czyli kluczowych wskaźników efektywności (KPI).
SOC w Konsorcjum PIONIER
Wychodząc naprzeciw potrzebom środowiska naukowego i akademickiego w zakresie podnoszenia poziomu cyberbezpieczeństwa, wynikającego z planowanych legislacji krajowych oraz NIS2, PCSS wspólnie z Jednostkami Wiodącymi Konsorcjum PIONIER podejmuje działania zmierzające do wdrożenia zarządzanych usług bezpieczeństwa i zaoferowania usług SOC w szczególności jednostkom podłączonym do sieci PIONIER.
Maciej Miłostan
