Cosa fa davvero un analista SOC Tier 1 tutto il giorno?
Uno sguardo ticket per ticket a cosa comporta realmente il lavoro SOC Tier 1, dal triage degli alert all'escalation, senza la patina delle brochure di reclutamento.
Gli annunci di lavoro per analista SOC Tier 1 sono volutamente vaghi perché il ruolo è principalmente triage ripetitivo, e le aziende sanno che "monitorare gli alert e investigare gli incident" suona meglio della realtà. Ecco come appare il lavoro dall'interno, ticket per ticket.
La coda non si svuota mai davvero
Inizi un turno e c'è una coda di ticket, di solito generati da un SIEM come Splunk, Microsoft Sentinel o QRadar. Ogni ticket è un alert: un login da un paese inusuale, un picco di traffico in uscita, un file che corrisponde a una regola YARA, un account utente bloccato cinque volte in dieci minuti. Un SOC occupato genera centinaia di questi al giorno, e la maggior parte sono il problema del Tier 1 per primo.
Apri un ticket. Ti dà un timestamp, un source IP, forse un nome utente, e la regola che si è attivata. Il tuo lavoro è rispondere a una domanda: è qualcosa, o è niente? È tutto qui. Non stai ancora risolvendo niente — stai decidendo se merita più attenzione.
Il triage è al 90% raccolta di contesto
Diciamo che l'alert è "impossible travel": un utente ha eseguito il login da Chicago e poi, 20 minuti dopo, da Francoforte. Prima di decidere qualcosa raccogli il contesto:
- Controlla il modello di login normale dell'utente nel SIEM — viaggia per lavoro, usa una VPN, ha un laptop che segnala male la geolocalizzazione?
- Controlla se l'MFA è stato soddisfatto su entrambi i login, o se il secondo ha utilizzato un token in cache.
- Cerca il source IP in qualcosa come VirusTotal o AbuseIPDB — è un nodo Tor noto, un provider VPN, un ISP residenziale?
- Contatta l'utente direttamente se il processo del tuo SOC lo consente — un messaggio Slack come "ehi, stavi facendo il login dalla Germania intorno alle 14?" risolve metà di questi ticket in una risposta.
La maggior parte delle volte è un client VPN che cambia server o un telefono che si sincronizza su LTE in una posizione strana. Scrivi quello che hai trovato, marcalo come falso positivo e chiudi il ticket. È il lavoro, ripetuto 30-60 volte a turno a seconda del volume del tuo SOC e della tua velocità.
Sapere quando fare escalation — e scriverla in modo che il Tier 2 non debba rifare il tuo lavoro
La vera abilità non è individuare il malware. È sapere quando qualcosa non torna abbastanza per fare escalation, e scrivere l'escalation in modo che il Tier 2 possa prenderla senza rifare il tuo triage da capo. Una cattiva escalation dice "login sospetto, please investigate." Una buona dice:
User: jsmith@company.com
Alert: Impossible travel (Chicago -> Francoforte, 22 min di distanza)
MFA: Soddisfatto su entrambi i login tramite notifica push
Source IP (Francoforte): 185.220.101.x — corrisponde alla lista di nodi Tor noti (punteggio AbuseIPDB 94)
Risposta utente: Nega il viaggio o l'uso di VPN; segnala di non aver ricevuto alcun prompt MFA per il secondo login (possibile push fatigue?)
Raccomandazione: Escalation — possibile compromissione dell'account tramite spam di push MFA. Consigliare reset forzato della password e revoca della sessione.
Quelle note hanno preso forse otto minuti ma ne risparmiano venti al Tier 2. Ticket come questo — dove l'utente nega l'attività e l'IP è segnalato — sono quelli che contano davvero, e sono forse il 5% della tua coda.
Gli strumenti che toccherai ogni singolo turno
Oltre al SIEM, aspettati di vivere in un pugno di strumenti ogni giorno: una console EDR (CrowdStrike Falcon, SentinelOne, Defender for Endpoint) per controllare gli alberi dei processi e isolare gli host se ti viene detto, un sistema di ticketing (ServiceNow, Jira) per tracciare il tuo lavoro, ricerche di threat intel (VirusTotal, AbuseIPDB, urlscan.io) per rapidi controlli IOC, e spesso un documento runbook o playbook che ti dice esattamente quali passaggi seguire per ogni tipo di alert. Il lavoro Tier 1 è pesantemente basato su playbook di proposito — la consistenza conta più dell'improvvisazione a questo livello.
Perché la ripetizione è in realtà l'addestramento
Il motivo per cui Tier 1 esiste come ruolo distinto, piuttosto che inviare ogni alert direttamente agli analisti senior, è il riconoscimento dei pattern attraverso il volume. Dopo poche centinaia di ticket di impossible travel inizi a riconoscere la forma di uno reale rispetto a un cambio di VPN ordinario prima ancora di aver finito di raccogliere il contesto. Questo istinto non viene da un corso — viene dal fare la versione noiosa del lavoro abbastanza a lungo che l'raro incident reale spicca davvero.
Se stai tracciando un percorso nel lavoro blue team, Korra Studio ha segmenti su le basi delle query SIEM, i workflow di triage del phishing, e cosa distingue le responsabilità Tier 1 da Tier 2 in pratica.
Scritto con assistenza AI, revisionato e pubblicato da Michal Pilch (CISSP), Korra Studio.
Questa è una nota dalla knowledge base di Korra Studio — la piattaforma abbina ogni argomento a mentoring 1-to-1.
Inizia gratisarrow_forward