Il miglior test di cybersecurity per assumere analiste SOC

Perché la maggior parte dei test per analiste SOC fallisce

Un'analista SOC (Security Operations Center) passa la giornata a leggere alert SIEM, prioritizzare le minacce e rispondere agli incidenti. Non scrive exploit né progetta reti. Eppure la maggior parte delle valutazioni di cybersecurity testa conoscenze di pentesting — vulnerability discovery, protocolli di rete, exploit chain.

Un'analista SOC forte può fallire un test di sicurezza di rete. Una pentester brillante può faticare come analista SOC. I set di skill si sovrappongono, ma le mansioni no.

Per assumere una buona analista, ti serve una valutazione che misuri: ragionamento di triage, analisi degli incidenti, gestione della fatica da alert e capacità di decidere sotto pressione di tempo.

Cosa fa davvero un'analista SOC

1. Triage: guardare 500 alert al giorno. Quali 5 meritano attenzione?
2. Investigazione: seguire i log tra i sistemi. Cosa è successo? Come sono entrati?
3. Escalation: è un incidente o un falso positivo? È critico per il containment o si debugga dopo?
4. Comunicazione: spiegare le scoperte a engineer che non parlano di security. Spingere indietro il rumore.

Una valutazione che non misura queste cose sta misurando la cosa sbagliata.

Anatomia di una valutazione SOC forte

Parte 1: triage degli alert (20 minuti)

Scenario: La tua dashboard SIEM mostra 47 alert. Hai 30 minuti prima del passaggio al turno successivo. Classifica i top 5 per priorità e spiega perché investigheresti ciascuno:

1. Tentativo di SQL injection (bloccato dal WAF) su /api/login
2. Login falliti a [email protected] da 5 paesi in 2 ore
3. SSH in uscita inatteso da un server di database verso un IP sconosciuto
4. 50 login falliti all'account di servizio app-runner dalla rete interna
5. Un file sensibile (/etc/passwd) copiato in una cartella esterna
6. Picco insolito di query DNS da una workstation di sviluppo
7. Un account utente riabilitato dall'IT 5 minuti fa (riabilitazione di routine)
8. Avviso di scadenza certificato su un web server (scade tra 30 giorni)

Cosa misuri:

• Sa distinguere segnale dal rumore?
• Pone domande di chiarimento (il contesto conta)?
• Ignorerà gli attacchi chiaramente bloccati o sovra-escalerà falsi positivi?
• Prioritizza per impatto di business, non per punteggio di severity?

Come si presenta una buona risposta: «Rango 1: #3 (SSH in uscita da database verso IP sconosciuto). Emergenza di containment se il database è compromesso. Rango 2: #2 (più paesi, stesso account). Rischio di credential stuffing, ma meno urgente con MFA — verifico. Rango 3: #5 (copia di passwd). Urgente solo se sono dati sensibili. Rango 4: #1 (SQL injection bloccata). Fatica da alert — il WAF ha fatto il suo lavoro. Salto #4, #6, #7, #8 nei prossimi 30 minuti.»

Parte 2: analisi di un incidente (40 minuti)

Scenario: Una sviluppatrice segnala che il suo laptop è lento. Il tuo team forensics rileva:

• 200 MB di dati compressi caricati su Slack 2 ore fa
• La cronologia di Chrome mostra git clone del monorepo aziendale
• Una chiave SSH nella cartella .ssh con data di modifica recente (stesso orario del caricamento)
• Nessun avviso antivirus

È un incidente di sicurezza? Qual è la tua teoria? Cosa fai nella prossima ora?

Cosa misuri:

• Sa costruire una timeline e una narrazione?
• Distingue tra «la utente ha caricato dati» e «un attaccante ha esfiltrato segreti»?
• Sa raccomandare il containment senza esagerare (non distruggere il laptop al sospetto)?
• Pensa ai falsi positivi (forse ha caricato codice di proposito)?

Come si presenta una buona risposta: «Sa di credenziali compromesse o rischio interno, ma devo prima escludere un'azione intenzionale. Io: 1) Parlo con la sviluppatrice — ha clonato il monorepo e l'ha condiviso intenzionalmente? 2) In caso negativo: controllo cosa c'era nell'archivio da 200 MB e chi ha accesso al canale Slack. 3) Assumo che la chiave SSH sia compromessa — la ruoto subito e verifico push o login non autorizzati nelle ultime 24 ore. 4) Se ci sono commit non autorizzati, è critico per il containment; altrimenti, è investigazione in corso. Non isolo ancora il laptop.»

Parte 3: scenario di fatica da alert (20 minuti)

Il tuo team di security sta annegando negli alert. I segnali veri sono sepolti sotto il rumore. Proponi di ridurre il volume degli alert con il tuning del SIEM. Quali alert sopprimeresti?

• Alert: «Tentativo di login fallito» (scatta 1.000 volte/giorno)
• Alert: «Cambio password da account admin» (scatta 50 volte/giorno, tutte legittime)
• Alert: «Trasferimento dati elevato verso storage cloud» (scatta 200 volte/giorno, soprattutto Google Drive di lavoro)
• Alert: «Processo senza firma valida lanciato» (scatta 10 volte/giorno, 90 % sono dev tool)

Cosa misuri:

• Sa ridurre il rumore senza perdere segnale?
• Capisce il tuning vs. ignorare?
• Chiederà contesto di business?

Come si presenta una buona risposta: «Sopprimo o sintonizzo #1 e #2 — non sono actionable. Per #1, faccio scattare l'alert su login falliti da nuovo IP + stesso utente. Per #2, niente alert su cambi password. Per #3, aggiungo il whitelisting per cloud tool legittimi (Google Drive, Dropbox, Slack). Per #4, whitelisting per dev tool tramite hash. L'obiettivo: far emergere i 2-3 alert al giorno che richiedono davvero indagine.»

Valutare l'assessment

L'intervista di follow-up

Abbina la valutazione a uno screen tecnico di 30 minuti:

• «Raccontami il tuo ultimo incidente SOC. Cosa ti ha fatto scalare? Cosa ti ha sorpreso?»
• «Ricevi un alert su malware. La firma è di 6 mesi fa. Come indaghi?»
• «Il tuo team ha 50 % di alert falsi positivi. Hai un'ora per proporre tuning. Qual è il tuo approccio?»

Il follow-up rivela se l'ha già fatto e se pensa pragmaticamente alla fatica da alert.

Perché conta

Il burnout delle analiste SOC è reale. Lasciano perché annegano negli alert e non vedono incidenti veri. Assumere qualcuno che sa fare triage in modo efficace è l'assunzione che migliora la velocità di tutto il team.

Una buona valutazione fa emergere candidate che sono state nel rumore e hanno imparato a trovare il segnale. Sono candidate rare. La valutazione dovrebbe trovarle.

Prossimi passi

Quando costruisci la tua valutazione SOC, concentrati su:

1. Triage (30 %)
2. Analisi degli incidenti (50 %)
3. Tuning degli alert (20 %)

Abbina a un colloquio live per confermare il giudizio sotto pressione. Le migliori assunzioni sono quelle in grado di spiegare il proprio ragionamento in tempo reale.

Le valutazioni ClarityHire supportano scenari SOC-specifici, upload di file (per l'analisi dei log) e risposte testuali (per le note aperte sugli incidenti). Costruisci la valutazione SOC che il tuo team vuole davvero.