Jak zbudować SOC w firmie – 7 kroków do skutecznego wdrożenia

Budowa Security Operations Center (SOC) wymaga zastosowania podejścia projektowego 

Nie znam przykładów udanych wdrożeń SOC, które zostały zainicjowane w sposób doraźny, niezaplanowany i niepoprzedzony czynnościami analitycznymi oraz konsultacjami. Pisząc o konsultacjach, nie mam tu na myśli wyłącznie zasięgnięcia opinii profesjonalnych doradców, a raczej (lub przede wszystkim!) konsultacji wewnętrznych –  z interesariuszami, na których SOC będzie oddziaływał. Ale po kolei. 

Krok 1: Opracuj uzasadnienie biznesowe

Spróbujmy wystartować od sformułowania uzasadnienia biznesowego dla budowy SOC w naszej organizacji. Być może przyczynkiem będzie Dyrektywa NIS2, presja otoczenia rynkowego lub – czego nikomu nie życzę – niedawny incydent cyberbezpieczeństwa.

Solidne uzasadnienie biznesowe przyda się praktycznie na każdym kroku wdrożenia, o czym warto na bieżąco przypominać interesariuszom. Zapewne wielu z nas pamięta, jak rozporządzenie RODO wpłynęło na implementację zabezpieczeń takich jak DLP. Z SOC mamy do czynienia z podobną historią, z tym że materia jest jeszcze bardziej skomplikowana. Dotykamy nie tylko technologii, ale i ludzi oraz procesów. Tak – ta triada cyberbezpieczeństwa, pomimo bycia „kliszą”, doskonale opisuje wyzwanie budowy SOC.

Przekonywujące i udokumentowane uzasadnienie biznesowe wspiera inwestycje, również te w cyberbezpieczeństwo. Warto pamiętać, że taki business case stanowi funkcję przeprowadzonej analizy ryzyka, zrozumienia kontekstu organizacyjnego oraz wymagań bezpieczeństwa, które płyną z celów biznesowych i najwyższego kierownictwa.

Krok 2: Zbierz informacje o potrzebach organizacji

Mając uzasadnienie biznesowe oraz zielone światło od najwyższego kierownictwa, można przejść do kolejnego kroku – zebrania odpowiednich informacji. Ten etap wymaga zagłębienia się w realne potrzeby organizacji.

Z doświadczenia wiem, że te ustalenia mogą być czasochłonne, dlatego już teraz przydaje się błogosławieństwo kierownictwa. Zwłaszcza że informacje będziemy czerpać również spoza naszego obszaru. Nie wykonuj tej pracy bez wstępnej akceptacji kierownictwa.

Po pierwsze: ustal, jakich usług potrzebujemy. Jakie konkretne funkcje powinien realizować SOC – od wykrywania zdarzeń, przez reagowanie na incydenty, aż po analizę złośliwego oprogramowania? Bazą wiedzy w tym obszarze może być FIRST CSIRT Services Framework 2.1.

To, jakie usługi będą świadczone przez SOC, będzie determinować wszystkie pozostałe aspekty: technologię, procesy czy niezbędne umiejętności budowanego zespołu. Przykładowo, jeżeli z analiz wynika, że SOC nie musi posiadać kompetencji w zakresie analizy złośliwego oprogramowania, to taka decyzja ma bezpośredni wpływ na koszty technologii, licencji i sprzętu. Chodzi o to, by planowanie zasobów odbywało się zawsze w odniesieniu do realnych potrzeb.

Warto zidentyfikować dotychczasowe incydenty i wyzwania bezpieczeństwa w organizacji, by na ich podstawie ustalić potrzeby i priorytety wdrażania. Przykładowo, jeżeli dotknął nas incydent typu ransomware, spróbujmy rozpocząć operacje od stworzenia scenariuszy zagrożeń i planów reakcji na ten typ ataku.

Rozważ warsztat z interesariuszami – stwórz mapę obecnych działań, ról i odpowiedzialności względem przyszłych funkcji SOC. W proces można zaangażować m.in. IT, dział prawny, PR, HR, bezpieczeństwo fizyczne, audyt wewnętrzny, a także właścicieli procesów i systemów.

Inne źródła wiedzy na tym etapie to opisy zasobów krytycznych, plany ciągłości działania (BCP), procedury bezpieczeństwa czy dokumentacja audytowa.

Na podstawie zebranych informacji oceń, które usługi SOC są absolutnie krytyczne i priorytetowe. Zastanów się też, czy część z nich można outsourcingować.

Krok 3: Opracuj koncepcję SOC

Gdy wiemy już, jaki zestaw usług powinien świadczyć nasz SOC, nadszedł czas na opracowanie koncepcji. W moim przekonaniu jest to udokumentowany opis architektury procesowo-organizacyjnej oraz technologicznej SOC, zharmonizowany z wybranym zakresem usług.

W tym miejscu definiujemy misję i cele działania, strukturę i model organizacyjny (wewnętrzny, hybrydowy, współdzielony?), zakres odpowiedzialności i uprawnień, niezbędne zasoby, a także zarysowujemy finansowanie początkowe i operacyjne. Ktoś, kto czyta Twoją koncepcję, powinien dowiedzieć się, co dokładnie będzie robił zespół SOC, dla kogo, w jakim zakresie, na jakich zasadach i w oparciu o jakie narzędzia.

Koncepcja jest szczegółowym rozwinięciem uzasadnienia biznesowego i musi być zatwierdzona przez interesariuszy. Zbieraj i wykorzystuj informacje zwrotne. Na podstawie zweryfikowanej koncepcji dopracuj szczegóły: strukturę zespołu, procesy,  zakresy odpowiedzialności, architekturę technologii.

Krok 4: Rozpocznij wdrożenie

Zrekrutuj i przeszkol osoby, które będą stanowić trzon zespołu – zarówno analityków, jak i osoby odpowiedzialne za procesy, utrzymanie technologii i koordynację wszystkich działań. Oprócz szkoleń stanowiskowych można rozważyć również transfer wiedzy i mentoring jako techniki zapewnienia odpowiedniego poziomu przygotowania.

Zadbaj o niezbędny sprzęt, licencje systemów, infrastrukturę oraz narzędzia wspierające zarządzanie incydentami i komunikację wewnętrzną. Materia techniczna jest na tyle złożona, że wymaga odrębnego omówienia, ale kieruj się tym, co zostało ustalone na początku: usługami. System SIEM, system ticketowy, repozytorium wiedzy czy feedy threat intelligence to oczywiste wybory w SOC, ale zastanów się nad innymi – maszyny do analizy złośliwego oprogramowania, wirtualne sieci do testowania reguł korelacyjnych, a może dodatkowy firewall pomiędzy siecią SOC a korporacyjną?

Zaprojektuj procesy i najważniejsze procedury, zbuduj również model obsługi incydentów i zdarzeń. Ogranicz dokumentację do niezbędnego minimum i staraj się, by jak najbardziej wspierała operacje. Jednocześnie pamiętaj, by procesy i procedury były zgodne z wymaganiami wyższego rzędu, np. polityki bezpieczeństwa informacji.

Jeżeli Twój SOC będzie również przyjmował zgłoszenia od użytkowników, to zadbaj o ich świadomość. Przygotuj proste, zrozumiałe materiały informacyjne: czym jest incydent, jak go zgłosić, jakie są typy, gdzie je zgłaszać i dlaczego to jest ważne.

Wszystkie powyższe aktywności możesz zrealizować własnymi siłami lub przy wsparciu zewnętrznych konsultantów. Jest to oczywiście decyzja biznesowa.

Krok 5: Wykonaj testy operacyjne

Zanim rozpoczniesz monitoring i obsługę zdarzeń „na produkcji”, dobrą praktyką jest wykonanie podstawowych testów operacyjnych. W tym celu przygotuj kilka scenariuszy, w których sprawdzisz, czy podstawowe funkcje SOC spełniają oczekiwania. W scenariuszach uwzględnij zarówno aspekt ludzki, jak i procesowy oraz techniczny. Określ minimalne informacje, jakie chcesz sprawdzić podczas każdego testu.

Na przykład w ramach scenariusza obsługi zdarzenia z nietypowym logowaniem upewnij się nie tylko, czy analiza zdarzenia została udokumentowana, ale również czy zadziałały mechanizmy pośrednie – poprawne parsowanie logów, odpowiednie przypisanie zdarzenia, kontakt z użytkownikiem czy właściwa synchronizacja czasu. To tylko jeden z możliwych scenariuszy.

Po odbytych testach wyciągnij wnioski i zastosuj poprawki, zanim ogłosisz gotowość operacyjną.

Krok 6: Ogłoś gotowość operacyjną

Gotowość operacyjna oznacza, że SOC jest funkcjonalny i gotowy do świadczenia usług (mogą to być tylko niektóre, priorytetowe usług, np. potrafi wykrywać zdarzenia w czasie rzeczywistym oraz obsłużyć incydent). Ta informacja musi dotrzeć do całej organizacji, by zespół mógł realnie wspierać jej cele biznesowe.

Wykorzystując dostępne kanały komunikacyjne, w komunikacie podaj komplet podstawowych informacji. Minimum to dane kontaktowe, godziny działania SOC, zakres obsługi i usług, linki, zakładka w intranecie. Wiadomość od CISO lub najwyższego kierownictwa lidera zwiększa zasięg, pokazuje, że zespół SOC ma poparcie zarządu i podnosi jego wiarygodność w oczach organizacji. Wybierz taki kanał komunikacyjny, który gwarantuje dotarcie do interesariuszy. Oczywiście, może on się różnić w zależności od odbiorcy, np. prezentacja będzie dobra dla rady dyrektorów, a wpis w intranecie dla pozostałych odbiorców.

Jeżeli to pasuje do kultury organizacyjnej, to zorganizuj onboarding użytkowników. Dni otwarte, spotkania z zespołem SOC, Q&A lub krótkie prezentacje dla działów to dobra okazja, by pokazać, czym zajmuje się zespół, jak reaguje i w czym może pomóc. Czasy, gdy zespół cyberbezpieczeństwa to enigmatyczny twór, który pełni rolę wewnętrznej policji i skupia się na kontroli powoli mijają. Taka postawa nie przystaje też do środowiska, w którym wymiana informacji to jedna z najcenniejszych rzeczy.

Krok 7: Przejdź do fazy ciągłego doskonalenia

SOC nie jest projektem z wyraźną datą zakończenia – to żywy organizm, który wymaga stałej uwagi i rozwoju. Regularnie dostrajaj reguły korelacyjne, optymalizuj procesy analityczne i dostosowuj modele zagrożeń do zmieniającego się krajobrazu ataków. Zbieraj feedback od użytkowników i interesariuszy, przeprowadzaj wewnętrzne audyty i oceniaj dojrzałość swoich operacji względem uznanych frameworków (np. SIM3 i/lub SOC-CMM). Dbaj również o ergonomię pracy i zdrowie analityków. Wypalenie zawodowe w SOC to realne zagrożenie, które może osłabić skuteczność całego zespołu.

Podsumowanie

Budowa SOC to złożony proces wymagający systematycznego podejścia – od uzasadnienia biznesowego, przez szczegółową analizę potrzeb i opracowanie koncepcji, aż po wdrożenie, testy i uruchomienie operacji. Kluczem do sukcesu jest zrozumienie, że SOC to nie jednorazowy projekt, lecz ciągłe doskonalenie w odpowiedzi na zmieniające się zagrożenia i potrzeby organizacji.