SOC SOC-owi nierówny – czym charakteryzuje się efektywna usługa SOC?

Problemy z pozyskaniem ekspertów do wewnętrznych zespołów SOC oraz wysokie koszty związane z tworzeniem wewnętrznych zespołów SOC sprawiają, że duża część organizacji współpracuje z zewnętrznymi partnerami SOC.

Niestety identyfikacja odpowiednich partnerów gwarantujących odpowiednią jakość usług (m.in. opieranie się na standardach obsługi incydentu) okazuje się często dużym problemem.

Coraz więcej partnerów oferuje usługę SOC w formie pasywnego przekazywania nieprzetworzonych informacji o incydentach do klienta bez uprzedniej analizy, bez zbudowania kontekstu zdarzenia czy bieżącego doradztwa, rekomendacji dotyczących szybkiej i skutecznej reakcji na zdarzenie, czy wsparcia w odtworzeniu systemu.

Dodatkowo część partnerów nie pomaga w dostosowania usługi SOC pod potrzeby konkretnego klienta, w tym m.in. w tworzeniu dedykowanej inżynierii detekcji – w miejsce wykorzystania domyślnych reguł dostawców narzędzi takich jak SIEM/XDR; bez kontekstu CTI – co skutkuje dużą liczbą fałszywych alertów (false positives) oraz niską efektywnością usługi SOC.

Poniższy artykuł przedstawia najlepsze praktyki, które oferują kompetentne zespoły SOC, ale również pomoże w ocenie zewnętrznych partnerów świadczących usługę SOC.

Czego oczekiwać od kompetentnego partnera SOC?

Usługa SOC powinna zostać poprzedzona dogłębną dyskusją (a najlepiej krótkim audytem), podczas której partner zrozumie unikalny kontekst systemów IT i biznesowych, działania oraz zależności biznesowe, otoczenie prawne czy posiadane narzędzia z obszaru bezpieczeństwa. Partnerzy muszą również uwzględniać obecne polityki organizacji. Bez tych informacji partnerzy nie są w stanie realnie ocenić ryzyka incydentu oraz jasno wskazać organizacjom akcji umożliwiających ograniczenie ryzyka.

  • Partner powinien wykazywać się dużą wiedzą domenową – absolutną podstawą jest zrozumienie obszaru bezpieczeństwa sieci i aplikacji. Partnerzy powinni rozumieć architekturę, narzędzia i protokoły współczesnych sieci na poziomie fizycznym, technologicznym czy administracyjnym.
  • Powinni również dobrze rozumieć współczesne narzędzia wykorzystywane do zarządzania incydentami, w tym m.in. narzędzia klasy IPS, IDS, SIEM, SOAR, UEBA, XDR, EDR czy firewalle.
  • W przypadku świadczenia usługi SOC partnerzy muszą posiadać technologie i procesy gwarantujące zbieranie informacji ze wszystkich źródeł istotnych dla wykrywania zagrożeń. 
  • Partner musi posiadać technologie, które gwarantują: 1) monitoring w czasie rzeczywistym, 2) retencję i agregację logów, 3) korelację oraz 4) samą analizę i detekcję. Retencja logów stanowi ważną informację z punktu widzenia budowania długoterminowej strategii bezpieczeństwa.
  • Działanie SOC powinno zostać zbudowane na standardach obsługi incydentu, np. frameworku „Incident Response”, co w praktyce oznacza współpracę z klientem nad skuteczną detekcją (identyfikacją zagrożeń), a w przypadku wystąpienia incydentu przeprowadzenie eradykacji (usunięcie zagrożenia), aż po pomoc w odtworzeniu systemu – współpracując z wewnętrznymi strukturami IT.
  • Mnogość zagrożeń, ilość grup przestępczych, szybkość ich działania w np. kreowaniu technik, taktyk i procedur wykorzystywanych do ataków sprawia, że w procesie obsługi incydentów powinny zostać wykorzystywane „feedy” z CTI, np. na poziomie branży czy globalnych informacji o zagrożeniach z różnego rodzaju baz czy forów. Partnerzy powinni zbierać relewantne informacje i korzystać z nich w bieżącej obsłudze incydentu.
  • Poza wykorzystywaniem obszaru CTI, efektywni partnerzy SOC oferują kompetencje w threat hunting, czyli proaktywne wyszukiwanie, rejestrację i neutralizację zagrożeń przed wystąpieniem poważnych konsekwencji.
  • Zarządzanie incydentami powinno również uwzględniać obszar podatności. Efektywna usługa SOC uwzględnia obszar podatności, a sam partner powinien szacować bieżące ryzyka wynikające z podatności.
  • Partner SOC powinien na bieżąco doradzać organizacji w poprawie ochrony oraz ograniczeniu ekspozycji na ryzyko – m.in. sugerując zmiany procesów czy narzędzi. Partnerzy powinni również wprowadzać zmiany w samej inżynierii detekcji czy reakcji na incydenty w celu ograniczenia false positives oraz poprawy efektywności działania SOC w sposób ciągły, ponadto zapewniając przejrzystą komunikację z klientem w każdym aspekcie swojej działalności.

Jak sprawdzić kompetencje partnera?
Samą weryfikację warto zacząć od otwartej dyskusji z partnerem, która umożliwi realną ocenę sposobu działania zespołu SOC i wykaże potencjalne braki. Poniżej prezentujemy przykładowe pytania:

  • Jak zespół SOC reaguje na incydent? (Czy klient dostaje nieprzetworzoną informację o incydencie czy może rekomendację pierwszej reakcji?)
  • Jakie role w ramach SOC posiada partner? (Czy mowa tylko o samych kompetencjach analitycznych czy może widzimy ekspertów domenowych – CTI, chmura, OT itd.)
  • Jakie informacje są wykorzystywane w procesie analizy incydentu?
  • Czy partner szacuje podatności?
  • Jakie kompetencje posiada partner poza samą obsługą narzędzi? (np. wiedza sieciowa, zrozumienie protokołów)
  • Czy partner posiada zasoby w całej Polsce umożliwiające wsparcie na miejscu w przypadku incydentu?
  • Czy partner posiada obszerną wiedzę z obszaru technologii i vendorów cyberbezpieczeństwa?
  • Na jakich narzędziach pracuje partner, czy posiada tylko własny zestaw, czy jest w tym zakresie elastyczny? 
  • I wiele innych

Poza samymi pytaniami warto jeszcze sprawdzić zgodność z certyfikatami czy frameworkami. Poniżej prezentujemy przykłady frameworków i certyfikatów.

Nie są to oczywiście jedyne słuszne źródła potwierdzające unikalne kompetencje, natomiast pokazują pewien stopień dojrzałości świadczonych usług i mogą zostać wykorzystane w procesie oceny partnerów:

Frameworki: SANS czy NIST 
Certyfikaty: CompTIA Security+, CompTIA CySA+, EC-Council Certified Incident Handler czy EC-Council Certified Ethical Hacker 
Modele i akredytacje: Trusted Introducer czy SIM3

Szukasz partnera SOC?
Umów się na konsultacje z zespołem Trecom SOC, w ramach których ustalimy Twoje potrzeby i powiemy o sposobie działania Trecom SOC.

12 listopada, 2024

Łańcuch dostaw pod lupą – co nowe regulacje oznaczają dla Twojego otoczenia biznesowego?

Liczba oraz skala ataków na i poprzez łańcuchy dostaw sprawiają, że coraz więcej organizacji zaczyna szukać najlepszych sposobów zabezpieczenia współpracy z […]

Czytaj artykuł ...
12 listopada, 2024

SOC SOC-owi nierówny – czym charakteryzuje się efektywna usługa SOC?

Problemy z pozyskaniem ekspertów do wewnętrznych zespołów SOC oraz wysokie koszty związane z tworzeniem wewnętrznych zespołów SOC sprawiają, że duża […]

Czytaj artykuł ...
6 sierpnia, 2024

Audyty i analizy luki w kontekście NIS 2

Jednym z obowiązków zdefiniowanych w projekcie nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa, która będzie implementować dyrektywę NIS 2 w Polsce […]

Czytaj artykuł ...
30 maja, 2024

Na co zwrócić uwagę przy wyborze partnerów oferujących usługę SOC?

Według Ministerstwa Cyfryzacji liczba firm podlegających pod dyrektywę NIS 2 w Polsce wynosi około 20 tysięcy. Ogromny niedobór ekspertów sprawia, że wiele organizacji będzie musiało zlecić zarządzanie incydentami zewnętrznym partnerom w formie usługi SOC. W artykule prezentujemy kluczowe kryteria, którymi warto kierować się przy wyborze partnerów SOC.

Czytaj artykuł ...
23 maja, 2024

Dlaczego powinieneś zacząć ochronę od poznania swoich zasobów?

Brak dokładnego zrozumienia i konfiguracji zasobów IT wiążę się często z brakiem wdrożenia efektywnych standardów bezpieczeństwa. Dowiedz się jak bazy CMDB pomagają w identyfikacji i zbieraniu informacji o infrastrukturze.

Czytaj artykuł ...
21 maja, 2024

Jak skutecznie podnieść świadomości w zakresie cyberbezpieczeństwa w Twojej organizacji?

Człowiek jest kluczowym elementem łańcucha bezpieczeństwa wpływającym na efektywną ochronę przed zagrożeniami. Poznaj praktyczne rozwiązania umożliwiające stworzenie programu podnoszenia świadomości cyberbezpieczeństwa dla pracowników organizacji.

Czytaj artykuł ...
20 maja, 2024

Zarządzanie ryzykiem w kontekście NIS 2

NIS 2 definiuje konkretne wymogi w ramach polityk analizy ryzyka czy zarządzania kryzysowego. Dowiedz się jak narzędzia klasy IT GRC pomagają w procesie zarządzania ryzykiem.

Czytaj artykuł ...

Umów się na bezpłatne
konsultacje z NIS 2

Serdecznie zapraszamy na konsultację, podczas których przejdziemy do praktycznych metod do spełnienia wymogów NIS 2 w Twojej organizacji.

Kontakt