Co naprawdę robi analityk SOC Tier 1 przez cały dzień?
Przegląd ticket po tickecie tego, co naprawdę obejmuje praca SOC Tier 1, od triażu alertów po eskalację, bez gladkich opisów z ogłoszeń o pracę.
Ogłoszenia o pracę dla analityka SOC Tier 1 są celowo niejasne, ponieważ rola to głównie powtarzalny triiaż, a firmy wiedzą, że "monitorowanie alertów i badanie incydentów" brzmi lepiej niż rzeczywistość. Oto jak ta praca wygląda od środka, ticket po tickecie.
Kolejka nigdy się naprawdę nie opróżnia
Zaczynasz zmianę, a w kolejce są tickety, zwykle generowane przez SIEM takie jak Splunk, Microsoft Sentinel lub QRadar. Każdy ticket to jeden alert: login z niezwykłego kraju, wzrost ruchu wychodzącego, plik pasujący do reguły YARA, konto użytkownika zablokowane pięć razy w dziesięć minut. Zajęty SOC generuje setki takich alertów dziennie, a większość z nich najpierw trafia do Tier 1.
Otwierasz ticket. Podaje ci timestamp, IP źródłowy, może nazwę użytkownika i regułę, która się uruchomiła. Twoja praca to odpowiedzieć na jedno pytanie: czy to coś znaczące, czy nic? To wszystko. Nie naprawiasz jeszcze niczego — decydujesz, czy to zasługuje na więcej uwagi.
Triiaż to 90% zbierania kontekstu
Załóżmy, że alert to "impossible travel": użytkownik zalogował się z Chicago, a następnie, 20 minut później, z Frankfurtu. Zanim cokolwiek zdecydujesz, zbierasz kontekst:
- Sprawdzasz normalny wzorzec logowania użytkownika w SIEM — czy podróżuje w celach zawodowych, używa VPN, ma laptop, który błędnie raportuje geolokalizację?
- Sprawdzasz, czy MFA było spełnione na obydwu loginach, czy drugi użył cache'owanego tokena.
- Wyszukujesz IP źródłowy w czymś takim jak VirusTotal lub AbuseIPDB — czy to znany wyjścia Tor, dostawca VPN, ISP mieszkaniowy?
- Jeśli proces twojego SOC na to pozwala, bezpośrednio kontaktujesz użytkownika — wiadomość na Slack takie jak "cześć, czy logujesz się z Niemiec około 14:00?" rozwiązuje połowę tych ticketów w jednej odpowiedzi.
W większości przypadków to przełączenie się klienta VPN między serwerami lub telefon synchronizujący się przez LTE w dziwnej lokalizacji. Spisujesz, co znalazłeś, oznaczasz to jako fałszywy alarm i zamykasz ticket. To praca, powtarzana 30-60 razy na zmianę w zależności od wielkości twojego SOC i twojej szybkości.
Wiedza, kiedy eskalować — i napisanie tego tak, żeby Tier 2 nie musiał powtarzać twojej pracy
Rzeczywista umiejętność to nie wykrycie złośliwego oprogramowania. To wiedza, kiedy coś nie się nie zgadza na tyle, żeby eskalować, i napisanie eskalacji tak, żeby Tier 2 mógł to przejąć bez ponownego robienia twojego triażu od zera. Zła eskalacja mówi "podejrzany login, proszę zbadać." Dobra eskalacja mówi:
User: jsmith@company.com
Alert: Impossible travel (Chicago -> Frankfurt, 22 min apart)
MFA: Satisfied on both logins via push notification
Source IP (Frankfurt): 185.220.101.x — matches known Tor exit node list (AbuseIPDB score 94)
User response: Denies traveling or using VPN; reports no MFA prompt received for second login (possible push fatigue?)
Recommendation: Escalate — possible account compromise via MFA push spam. Recommend forced password reset and session revocation.
Ten opis zajął może osiem minut, ale zaoszczędza Tier 2 dwadzieścia. Tickety takie jak ten — gdzie użytkownik zaprzecza aktywności, a IP jest oflagowane — to te, które naprawdę się liczy, i stanowią może 5% twojej kolejki.
Narzędzia, których będziesz dotykać każdą zmianę
Poza SIEM, spodziewaj się mieszkać w kilku narzędziach dziennie: konsoli EDR (CrowdStrike Falcon, SentinelOne, Defender for Endpoint) do sprawdzenia drzew procesów i izolacji hostów, jeśli dostaniesz polecenie, system ticketów (ServiceNow, Jira) do śledzenia swojej pracy, wyszukiwania threat intel (VirusTotal, AbuseIPDB, urlscan.io) do szybkich kontroli IOC, i często dokument runbook lub playbook, który mówi ci dokładnie, jakie kroki wykonać dla każdego typu alertu. Praca Tier 1 jest celowo napędzana playbookami — spójność ma większe znaczenie niż improwizacja na tym poziomie.
Dlaczego powtórzenie to faktycznie trening
Powód, dla którego Tier 1 istnieje jako odrębna rola, zamiast wysyłania każdego alertu bezpośrednio do starszych analityków, to rozpoznawanie wzorców poprzez objętość. Po kilkastu setkach ticketów impossible travel zaczynasz rozpoznawać kształt prawdziwego zanim nawet skończysz zbierać kontekst, w porównaniu z rutynowym przełączeniem VPN. Ten instynkt nie pochodzi z kursu — pochodzi z robienia nudnej wersji pracy na tyle długo, że rzadki prawdziwy incydent faktycznie się wyróżnia.
Jeśli planujesz ścieżkę w pracy blue team, Korra Studio ma segmenty na temat podstaw zapytań SIEM, workflow triażu phishingu i co odróżnia odpowiedzialność Tier 1 od Tier 2 w praktyce.
Napisane z pomocą AI, zweryfikowane i opublikowane przez Michal Pilch (CISSP), Korra Studio.
To jedna notatka z bazy wiedzy Korra Studio — platforma łączy każdy temat z mentoringiem 1 na 1.
Zacznij za darmoarrow_forward