Security Analyst vs Security Engineer: Qual è la vera differenza?

I titoli vengono usati in modo intercambiabile negli annunci di lavoro, ma il lavoro quotidiano è genuinamente diverso. Se stai scegliendo una direzione su cui concentrarti, capire la differenza ti farà risparmiare mesi a inseguire certificazioni e competenze sbagliate.

Quello che un analyst fa davvero tutto il giorno

Un security analyst passa la maggior parte del tempo a osservare, fare triage e investigare. Significa stare davanti a un SIEM (Splunk, Sentinel, QRadar), gestire code di alert e decidere se un processo segnalato su una workstation è un falso positivo o l'inizio di un incidente. Una parte importante del lavoro è scrivere i risultati in modo chiaro affinché un manager o un cliente senza background di sicurezza possa capire cosa è successo.

Gli analyst di Tier 1 fanno triage. Gli analyst di Tier 2/3 scavano più a fondo — estraggono process tree, controllano la telemetria dell'EDR in qualcosa come CrowdStrike o Defender for Endpoint, correlano i log tra firewall e identity provider per costruire una timeline. Il lavoro è reattivo per natura: succede qualcosa, tu capisci cosa significa e cosa fare.

Una lista di task tipica per un analyst: rivedere gli alert notturni, chiudere i falsi positivi con motivazioni documentate, escalare un'esecuzione di PowerShell sospetta, aggiornare un runbook dopo che appare un nuovo pattern di phishing, e partecipare a una call di incidente. È un lavoro investigativo e ricco di comunicazione.

Quello che un engineer costruisce davvero

Un security engineer costruisce e mantiene i sistemi su cui l'analyst si affida. Significa scrivere regole di detection in Sigma o KQL, ottimizzare un SIEM per non allagare la coda con rumore, distribuire e configurare agenti EDR su 5.000 endpoint, oppure automatizzare un playbook di risposta al phishing in una piattaforma SOAR come Tines o Cortex XSOAR.

Gli engineer lavorano anche a monte degli incidenti: hardening delle configurazioni cloud su AWS o Azure, configurazione della segmentazione della rete, scrittura di Terraform per applicare le regole dei security group, patching delle pipeline CI/CD per evitare che i secret finiscano nella storia di git. Molti lavori di engineering sono invisibili finché non si rompono — nessuno nota una regola WAF ben configurata, ma tutti notano quando manca.

Dove un analyst chiede "cosa è successo qui", un engineer chiede "come fermiamo questa classe di problema, o almeno la individuiamo più velocemente la prossima volta". Gli engineer scrivono codice più spesso — Python per l'automazione, a volte Go o Rust per tooling, YAML e Terraform per l'infrastruttura.

Competenze che realmente separano i due ruoli

Gli analyst hanno bisogno di forte pattern recognition, fluidità nell'analisi dei log e capacità di scrivere report di incidente sotto pressione di tempo. Strumenti: Splunk SPL, Wireshark, triage malware base, mappatura MITRE ATT&CK. Certificazioni che funzionano bene: Security+, CySA+, GCIH, a volte verso GCFA per lavori di forensics più approfonditi.

Gli engineer hanno bisogno di costruire davvero le cose: scripting (Python, Bash), infrastructure-as-code, integrazione API tra tool di sicurezza, e abbastanza conoscenza di sistemi e rete per sapere perché una regola rompe la produzione. Le certificazioni qui tendono verso GCED, cloud security cert (AWS Security Specialty, AZ-500), e infine OSCP se il ruolo pende verso l'offensive-adjacent.

La sovrapposizione è reale — un buon analyst impara a scrivere le proprie query di enrichment, e un buon engineer ha ancora bisogno di leggere i log per sapere se la detection che ha scritto si attiva realmente. Ma il centro di gravità differisce: gli analyst vivono nella coda degli alert, gli engineer vivono nei file di configurazione e nei code repo.

Percorsi di carriera e come le persone si muovono tra loro

La maggior parte delle persone inizia come analyst perché i ruoli SOC assumono più posizioni entry-level e la curva di apprendimento ti insegna come è "normale" in un ambiente reale. Quella base è importante anche se alla fine vuoi fare engineering.

Da analyst di Tier 1, un percorso comune è analyst di Tier 2/3, poi o threat hunter o detection engineer, che è un vero ruolo ibrido che scrive detection basate su cosa gli analyst vedono mancato nella coda. Da lì, alcuni si spostano completamente in security engineering (costruire piattaforme) o architecture (progettare programmi di sicurezza completi).

Gli engineer a volte vengono da una porta completamente diversa — developer software o sysadmin che acquisiscono specializzazione di sicurezza piuttosto che iniziare in un SOC. Quel percorso salta la fase di alert fatigue ma può lasciare lacune negli istinti di incident response.

Per quale dovresti mirare per primo

Se ti piace investigare, scrivere e risolvere puzzle sotto pressione, inizia dal lato analyst. Se preferisci scrivere codice e risolvere le cause root piuttosto che inseguire alert, mira al lato engineer, ma aspettati di aver bisogno di un'esperienza simile a quella di un analyst per essere credibile — nessuno si fida di una detection che hai scritto se non hai mai dovuto gestire una coda di alert tu stesso.

Entrambi i percorsi convergono infine ai livelli senior, dove il lavoro diventa meno una questione di titolo e più una questione di capire tutta la superficie di attacco. Korra Studio ha segmenti su flussi di lavoro SOC, scrittura di query SIEM e fondamenti di cloud security engineering che vale la pena esplorare se vuoi vedere da vicino il tooling quotidiano per entrambi i percorsi.