SOC checklist część 2: codzienne zadania, których nie widać

Poprzedni artykuł opisywał te najbardziej książkowe elementy pracy SOC — monitorowanie, triage alertów, analizę incydentów, podatności, threat hunting czy raportowanie. To zadania, które łatwo nazwać, rozpisać w procedurach i w razie potrzeby zmierzyć liczbą ticketów, czasem reakcji albo statystykami z SIEM.

Ale jest też drugi świat. Mniej formalny i dużo mniej widoczny. To miękkie aktywności, które dzieją się obok głównych zadań i często nie mają rozpisanego procesu. To rzeczy, które nie kończą się ticketem i nie lądują w statystykach, a jednocześnie potrafią zająć dużą część codziennej pracy.

To tu buduje się bezpieczeństwo na co dzień: szybka pomoc użytkownikom, krótkie edukowanie przy okazji, wyłapywanie sygnałów z internetu i przekładanie ich środowisko, czy dogadywanie się z innymi zespołami IT i łapanie kontekstu. Tego nie widać w raportach, ale bez tego SOC działa gorzej — nawet jeśli „na papierze” wszystko się zgadza.

Gaszenie małych tematów od ręki

W codziennej pracy SOC wpadają też tematy, które nie powinny tu trafiać. A jednak trafiają. Kierownik pisze na alias, aby przyspieszyć proces. Użytkownik pyta na komunikatorze, bo tak mu wygodniej. Ktoś prosi o poradę, bo nie wie do kogo może się zgłosić. W każdej firmie prędzej czy później pojawia się drugi obieg. Część spraw idzie skrótem, poza oficjalnymi kanałami. Można z tym walczyć, ale zwykle kończy się nerwami po obu stronach. Lepiej mieć proste podejście. Pomagamy, jeśli możemy i jeśli mamy czas. A przy okazji kierujemy temat tam, gdzie powinien trafić. Przy okazji SOC często wyłapuje rzeczy, które zahaczają o bezpieczeństwo, np. prośby o udostępnienie danych, nietypowe uprawnienia czy omijanie procedur.

Uświadamianie w codziennych sytuacjach

Te tematy, które wpadają do SOC bokiem, często mają drugi efekt. Jest to dobry moment, aby przekazać użytkownikom wiedzę na temat dobrych praktyk na konkretnym przykładzie. Uświadamianie rzadko wygląda jak formalne szkolenie. Najczęściej dzieje się przy okazji rozmowy. Ktoś pyta, czy może wysłać plik na prywatnego maila, ktoś chce udostępnić folder, ktoś prosi o instalację wtyczki. I wtedy SOC ma okazję coś wyjaśnić. Bez wykładu i bez straszenia. Po prostu: możesz, ale zrób to tak. Tego nie rób, bo to ryzyko. Czasem wystarczą dwie linijki na Teamsach. krótki telefon, czy screen z zaznaczonym miejscem, po którym widać phishing. To działa, bo ludzie dostają przykład z własnej pracy, a nie teorię ze slajdu. I następnym razem częściej pytają wcześniej, zamiast zgłaszać problem po fakcie.

Co nowego na świecie i czy nas to dotyczy

To nie jest zadanie z checklisty. Ktoś w SOC czyta w wolnej chwili o nowej sztuczce w phishingu, ciekawym obejściu, sprytnym sposobie na utrzymanie dostępu albo po prostu o tym, jak wyglądał czyjś incydent. I zamiast zostawić to jako ciekawostkę, pojawia się pytanie: czy u nas też by to przeszło bokiem. Wtedy wykonywany jest szybki przegląd: jedno-dwa zapytania, sprawdzenie czy mamy logi pod taki scenariusz. Jeśli da się coś wyciągnąć, dokładamy gotowe query, prostą detekcję albo chociaż opis, gdzie patrzeć następnym razem. Nie ma z tego ticketu oraz często nikt tego nie mierzy. Ale dzięki takim małym próbom SOC nie stoi w miejscu i szybciej łapie rzeczy, które dopiero za chwilę staną się popularne.

Łączenie faktów i dogadywanie się z IT

SOC często jest w środku, bo dotyka wszystkich warstw. Jak coś się dzieje, trzeba szybko ustalić podstawy: co to za system, kto jest właścicielem, co jest normalne, co było zmieniane, kto ma dostęp i czy ktoś już nad tym pracuje. Tego nie da się wyciągnąć wyłącznie z narzędzi. Trzeba znać ludzi i mieć z nimi dobry kontakt. Jednocześnie SOC ma dość szeroki obraz środowiska, bo przewija się przez niego wszystko: sieć, endpointy, tożsamość, chmura, serwery, aplikacje. Dzięki temu może być pomostem, gdy zespoły mówią różnymi językami. Sieciowiec patrzy na ruch, admin na serwer, czy błędy w logach, a SOC skleja to w jedną historię i potrafi powiedzieć, gdzie znajduje się brakujący element. To nie jest formalne zadanie w harmonogramie, ale bez tego reakcja na zdarzenia i codzienne triage trwają dwa razy dłużej.

Małe sugestie, duży efekt

Z tych wszystkich rozmów i szybkich sprawdzeń często wychodzą drobne rzeczy, które da się poprawić. I tu ważne: SOC nie przejmuje kompetencji IT ani nie robi hardeningu za innych. Raczej podrzuca konkretne sugestie, najlepiej z krótkim uzasadnieniem i przykładem. Typowo są to małe tematy, które ktoś przegapił w codziennej pracy: za szerokie uprawnienia, konto serwisowe bez sensownego ograniczenia, brak MFA w jednym miejscu, niepotrzebnie otwarty port,  albo ustawienie, które „kiedyś było na chwilę” i zostało na stałe. SOC to wyłapuje, bo widzi skutki w logach i alertach. Potem idzie krótka wiadomość do właściciela systemu: co widać, czemu to może być ryzykowne i co warto zmienić. Bez narzucania, bez wchodzenia w czyjeś zadania. Po prostu: mamy obserwację, mamy propozycję, warto to poprawić.

Podsumowanie

Nie wszystko w SOC da się zamknąć w procedurę i umieścić w raporcie. Duża część pracy to szybkie wsparcie, krótkie wyjaśnienia i łapanie kontekstu z różnych miejsc. To buduje zaufanie i sprawia, że informacje szybciej trafiają do właściwych osób. I właśnie to często decyduje, czy SOC jest „zespołem od monitorowania”, czy zespołem, który realnie podnosi bezpieczeństwo firmy.

---