Carriere nella sicurezza informatica: quale ruolo fa per te?

La sicurezza informatica comprende mestieri molto diversi. C'è chi passa la giornata a leggere alert in una console di monitoraggio. Altri testano applicazioni web con il permesso del proprietario, scrivono il codice che blocca quei bug o ricostruiscono dalle prove cosa è successo a un portatile compromesso. Se stai iniziando o cambiando carriera, il modo più rapido per scegliere è confrontare com'è il lavoro giorno per giorno, poi provare uno o due ruoli con esercizi gratuiti prima di pagare un corso.

Questo articolo copre otto ruoli comuni: analista SOC, incident responder, application security (AppSec) engineer, penetration tester, analista DFIR (digital forensics and incident response), analista di vulnerability management, analista GRC (governance, risk and compliance) e security engineer. Per ciascuno trovi il lavoro quotidiano, le competenze di base, un primo esercizio che non costa nulla e gli articoli del Manuale da campo che allenano quelle competenze. L'ultima sezione è una scheda di lavoro. Scegli due ruoli, elenca tre competenze per ciascuno e decidi quale articolo leggere per primo.

I nomi delle posizioni cambiano da un datore di lavoro all'altro. Prendi queste descrizioni come un quadro di massima del mestiere, senza aspettarti che dicano con certezza cosa comprende una posizione specifica.

#Come sono organizzati i ruoli

#Che cos'è il NICE Framework

Il NIST descrive il NICE Framework come "un linguaggio comune che descrive il lavoro nella sicurezza informatica". Il framework è documentato nella NIST Special Publication 800-181 Revision 1, pubblicata in versione definitiva nel novembre 2020. Raggruppa i work role in categorie e aree di specializzazione, e descrive ogni ruolo con i compiti, le conoscenze e le competenze che richiede. Datori di lavoro, scuole e programmi di formazione usano questo vocabolario, quindi un annuncio che nomina un ruolo parla spesso la lingua del NICE anche quando aggiunge parole sue.

Il CISA Cyber Career Pathways Tool, pubblicato tramite la National Initiative for Cybersecurity Careers and Studies (NICCS), ti permette di selezionare un work role, leggerne le descrizioni e confrontare due ruoli affiancati. Lo strumento dichiara di usare i NICE Framework Components versione 2.2.0. Per ogni ruolo qui sotto trovi il work role più vicino, con il nome che ha nello strumento. I nomi dei ruoli del framework sono generici (Defensive Cybersecurity, Digital Forensics) e diversi dai nomi delle posizioni lavorative, e i componenti sono stati rivisti dopo la pubblicazione del 2020, quindi controlla ciascuno nello strumento prima di citarlo in un curriculum.

#Perché il ruolo conta più dello strumento

Chi comincia parte spesso da un elenco di strumenti: Nmap, Burp Suite, Wireshark, Splunk. Uno strumento serve a rispondere a una domanda, e la domanda la decide il ruolo. Un analista SOC si chiede se un alert descrive un evento reale e cos'altro ha fatto quell'host. Un penetration tester si chiede cosa potrebbe raggiungere un attaccante all'interno di un perimetro concordato. Un analista GRC si chiede se i controlli corrispondono al rischio messo per iscritto. Scegli prima la domanda. Gli strumenti vengono di conseguenza.

#Gli otto ruoli

#1. Analista SOC

Work role NICE più vicino: Defensive Cybersecurity.

Lavoro quotidiano. Un analista di un security operations center (SOC) lavora su una coda di alert. Ogni alert passa dal triage: è un vero positivo, un falso positivo o qualcosa da guardare più da vicino? Gran parte della giornata se ne va a leggere eventi nei log, a risalire da un evento a quelli intorno, a controllare se un utente o un host si è comportato come previsto e a scrivere note brevi che un altro analista possa seguire. Tutto quello che sembra un incidente reale passa ai responder.

Competenze di base. Leggere i log, riconoscere gli eventi comuni di Windows e Linux, basi di rete (DNS, HTTP, porte), scrivere query di ricerca, documentare con chiarezza e sapere quando fare escalation.

Primo esercizio gratuito. Sul tuo PC Windows apri PowerShell come amministratore e leggi gli ultimi 20 eventi di accesso non riuscito dal log Security. L'Event ID 4625 è l'evento di accesso non riuscito. Non ho eseguito questo comando per questo articolo, quindi vedrai quello che registra la tua macchina:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20 | Select-Object TimeCreated, Message

Annota cosa significa ogni evento e se riconosci l'account. Anche un elenco vuoto è un risultato. Non leggere i log di macchine che non sono tue.

Da leggere prima: Che cos'è un SIEM? Log, query e alert, Come funziona HTTP, File e permessi su Linux.

#2. Incident responder

Work role NICE più vicino: Incident Response.

Lavoro quotidiano. I responder prendono in mano la situazione quando un alert diventa un incidente. Coordinano il contenimento (isolare un host, disabilitare un account, bloccare un indirizzo), l'eradicazione (eliminare la via d'accesso usata dall'attaccante) e il ripristino. Tengono una timeline, aggiornano IT, ufficio legale e direzione, e decidono quando l'incidente è chiuso. Buona parte del lavoro consiste nel comunicare con chiarezza quando il tempo stringe.

Competenze di base. Triage, valutare i compromessi del contenimento, costruire una timeline, scrivere aggiornamenti di stato, capire come phishing e credenziali rubate si muovono di solito in una rete, e basi di gestione delle prove, così che l'analisi successiva resti possibile.

Primo esercizio gratuito. Scrivi in un file di testo semplice la timeline di un caso inventato. Per esempio: "10:02 l'utente apre un allegato; 10:04 compare una nuova attività pianificata; 10:10 connessione in uscita verso un indirizzo sconosciuto." Accanto a ogni riga scrivi quale log o artefatto la confermerebbe. Non ti servono strumenti. La competenza sta nel mettere in fila i fatti e separare quello che sai da quello che sospetti.

Da leggere prima: Come scrivere il tuo primo report di sicurezza, Threat modeling con STRIDE, Che cos'è un SIEM?.

#3. Application security (AppSec) engineer

Work role NICE più vicino: Software Security Assessment, spesso insieme a Secure Software Development.

Lavoro quotidiano. Gli AppSec engineer aiutano i team di sviluppo a evitare le vulnerabilità prima del rilascio. Rivedono progetti e codice, forniscono pattern sicuri e librerie condivise, impostano controlli automatici nelle pipeline di build e passano in rassegna i finding con gli sviluppatori responsabili del codice. Una buona giornata finisce spesso con un bug corretto invece che con un lungo report.

Competenze di base. Fondamenti del web (HTTP, cookie, sessioni, regole same-origin), almeno un linguaggio di programmazione, le categorie della OWASP Top 10, validazione dell'input e codifica dell'output, e saper leggere codice scritto da altri.

Primo esercizio gratuito. Esegui sulla tua macchina OWASP Juice Shop, un'applicazione web volutamente vulnerabile. Associala a localhost, così solo il tuo computer può raggiungerla. Deve essere installato Docker. Non ho eseguito questo comando per questo articolo, quindi l'output è quello che stampa il tuo ambiente:

docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Apri http://localhost:3000 nel browser, scegli una sfida per principianti e annota la causa di fondo e la correzione che applicherebbe uno sviluppatore. Quando hai finito, ferma il container.

Da leggere prima: OWASP Top 10 per sviluppatori, La SQL injection spiegata con Juice Shop, Che cos'è il CSRF e come aiutano i cookie SameSite.

#4. Penetration tester

Work role NICE più vicino: nessuno con questo titolo. Lo strumento non ha un ruolo di penetration tester, quindi leggi Vulnerability Analysis e Threat Analysis per i compiti più simili.

Lavoro quotidiano. I penetration tester valutano sistemi che il proprietario ha accettato di far testare, dentro un perimetro scritto e con regole d'ingaggio. Mappano il target, cercano debolezze, confermano l'impatto senza causare danni e scrivono finding su cui uno sviluppatore o un amministratore possa intervenire. Gran parte del valore professionale sta nel report e nel giudizio su cosa conta. L'output di uno scanner, da solo, non è un finding.

Competenze di base. Networking, basi di web e directory, scripting, disciplina sul perimetro, valutazione del rischio con CVSS, scrittura dei report e una solida comprensione del perimetro.

Primo esercizio gratuito. Scrivi un documento di perimetro per il tuo laboratorio prima di toccare qualsiasi cosa. Usa il container Juice Shop dell'esercizio AppSec o una macchina virtuale tua. Elenca cosa rientra nel perimetro (questo container su localhost, porta 3000), cosa resta fuori (tutto il resto, compresi il tuo router, le reti dei vicini e qualsiasi sito che non è tuo), chi ha dato il permesso per il lavoro e gli orari di inizio e fine. L'esercizio è il documento. I test cominciano solo dopo che esiste.

Da leggere prima: Che cos'è una vulnerabilità?, Che cos'è il CVSS?, OSINT: etica e privacy, Come creare una rete Docker isolata per i laboratori.

#5. Analista DFIR

Work role NICE più vicino: Digital Forensics.

Lavoro quotidiano. Un analista DFIR esamina le prove provenienti da sistemi forse compromessi: immagini disco, acquisizioni della memoria, log degli eventi, artefatti del browser e dei file. Lo scopo è ricostruire cosa è successo, registrare come si è arrivati a ogni conclusione e mantenere inalterate le prove. Gli incident responder decidono cosa fare dopo; gli analisti DFIR spiegano cosa è successo, con le prove in mano.

Competenze di base. File system, hash dei file, artefatti di Windows e Linux, strumenti di analisi di disco e memoria, catena di custodia, appunti accurati e abbastanza conoscenza del malware da descriverne il comportamento senza eseguire campioni su una macchina normale.

Primo esercizio gratuito. Calcola l'hash SHA-256 di un file scaricato da una fonte affidabile. Gli hash sono lo strumento di base per dimostrare che una prova non è cambiata. In Git Bash, su un file a tua scelta:

sha256sum ~/Downloads/example.pdf

Registra l'output accanto al nome del file e alla data. Se chi pubblica il file indica un hash per il download, confronta i due valori. Il controllo dell'hash legge il file e non lo esegue mai. Non aprire e non eseguire file sconosciuti per vedere cosa fanno.

Da leggere prima: Hash dei file e VirusTotal: etica, File e permessi su Linux, Che cos'è Bash? Basi della shell per chi studia sicurezza.

#6. Analista di vulnerability management

Work role NICE più vicino: Vulnerability Analysis.

Lavoro quotidiano. Chi si occupa di vulnerability management tiene un inventario degli asset e delle loro debolezze note, decide quali correzioni vengono prima, segue responsabili e scadenze e riferisce sui progressi. La parte difficile è dare le priorità. Uno scanner può produrre migliaia di finding, e il lavoro consiste nel decidere quali contano per questa organizzazione questa settimana, in base a cosa è esposto su internet e a cosa serve all'azienda per funzionare.

Competenze di base. Inventario degli asset, lettura dei record CVE e CVSS, conoscenza dei cicli di patch, priorità in base al rischio, lavoro con i responsabili dei sistemi e flussi di lavoro a ticket.

Primo esercizio gratuito. Apri un CVE recente sul sito pubblico NVD (nvd.nist.gov). Leggi la descrizione e il vettore CVSS. Poi scrivi tre frasi: qual è il difetto, quali condizioni servirebbero a un attaccante e cosa farebbe un proprietario responsabile su un sistema che gestisce. Consultazioni pubbliche come questa sono innocue. Non interrogare e non testare sistemi che non sono tuoi.

Da leggere prima: Che cos'è una vulnerabilità?, Che cos'è il CVSS?.

#7. Analista GRC

Work role NICE più vicino: Security Control Assessment, che si sovrappone a Cybersecurity Policy and Planning.

Lavoro quotidiano. Gli analisti GRC (governance, risk and compliance) trasformano i requisiti di sicurezza in policy, controlli e prove. Tengono aggiornati i registri dei rischi, raccolgono le prove per gli audit, controllano se i fornitori rispettano i termini del contratto e aiutano la direzione a decidere quali rischi accettare, ridurre o trasferire. Il terminale si usa poco. Buona parte del lavoro è lettura attenta e verifica di quanto è scritto rispetto a quello che i sistemi fanno davvero.

Competenze di base. Scrittura di policy, valutazione del rischio, framework comuni come il NIST Cybersecurity Framework e ISO/IEC 27001, raccolta delle prove, interviste con le parti interessate e scrittura chiara.

Primo esercizio gratuito. Scrivi un registro dei rischi di una pagina per il tuo portatile. Usa cinque righe: dispositivo smarrito, password debole, sistema operativo non aggiornato, phishing e backup non riuscito. Per ogni riga scrivi probabilità e impatto a parole semplici, il controllo che usi oggi e un prossimo passo. Tienilo in un file di testo. Se riesci a spiegare in una frase perché un controllo conta, stai facendo il lavoro.

Da leggere prima: Threat modeling con STRIDE, Che cosa sono HTTPS e TLS?, Cifratura, codifica e hashing a confronto.

#8. Security engineer

Work role NICE più vicino: Cybersecurity Architecture e Secure Systems Development.

Lavoro quotidiano. I security engineer progettano e costruiscono sistemi di protezione: gestione di identità e accessi, single sign-on e autenticazione a più fattori, segmentazione di rete, gestione dei segreti, configurazioni di base sicure e pipeline di rilevamento. Lavorano tra sviluppo e operations, e misurano se un controllo funziona dopo il deploy, oltre a verificare che sia stato installato.

Competenze di base. Amministrazione di sistemi operativi (Linux o Windows), crittografia a livello d'uso (chiavi, hashing, TLS), identità e privilegio minimo, infrastructure as code, scripting e un controllo attento delle modifiche.

Primo esercizio gratuito. Crea una coppia di chiavi SSH sulla tua macchina e impara qual è il file pubblico. Non ho eseguito questo comando per questo articolo, quindi l'output dipende dalla tua configurazione. Scegli una passphrase quando ti viene chiesta:

ssh-keygen -t ed25519 -f ~/.ssh/lab_ed25519 -C "lab key"

Poi elenca ~/.ssh. Il file che finisce in .pub è quello che puoi condividere. Il file senza estensione è la chiave privata, e non deve mai finire in una chat, in un commit o in uno screenshot.

Da leggere prima: Chiavi pubbliche e private spiegate, Che cos'è SSH e come funzionano le chiavi SSH?, Come funziona l'hashing delle password con Argon2id.

#Scegli con la scheda

Questo articolo non ha un laboratorio che richieda un server. L'esercizio è un'autovalutazione e richiede circa 30 minuti.

1. Scegli dall'elenco due ruoli che ti interessano, anche se non sei sicuro di saperli fare.
2. Per ogni ruolo annota tre competenze che hai già e tre che dovresti costruire. Sii onesto. "Leggere i log" e "usare Linux" vanno bene se oggi li sai fare.
3. Per ogni ruolo scegli un articolo del Manuale da campo da cui partire, dall'elenco Da leggere prima.
4. Fai il primo esercizio gratuito di ogni ruolo. Annota cosa ha richiesto più tempo del previsto.
5. Cerca entrambi i ruoli nel CISA Cyber Career Pathways Tool e confronta affiancate le descrizioni dei loro work role.

Copia questo modello in un file di testo:

Role 1:
  Skills I have:
    1.
    2.
    3.
  Skills I need to build:
    1.
    2.
    3.
  Article to start with:
  First practice step done on (date):
  What surprised me:

Role 2:
  (same lines as above)

La scheda è finita quando riesci a dire in due frasi quale ruolo proveresti per primo e perché.

#Errori comuni

Scegliere solo in base al titolo. Lo stesso titolo significa cose diverse da un datore di lavoro all'altro. Prima di decidere leggi il lavoro quotidiano e l'elenco delle competenze.

Cominciare dagli strumenti offensivi. Saper lanciare uno scanner non ti insegna cosa significa il suo output. Impara prima come funzionano le reti, le richieste web e i permessi di Linux.

Saltare il perimetro. Qualsiasi esercizio contro un sistema che non è tuo è un problema legale ed etico, anche quando il target sembra innocuo. In questo articolo si parte solo dal tuo container, dalla tua macchina e da un perimetro scritto ed esplicito.

Prendere un corso completato come prova. Un certificato dimostra che hai studiato. Una timeline, un registro dei rischi, un documento di perimetro o un bug corretto mostrano cosa sai produrre. Conserva gli artefatti di ogni esercizio.

Eseguire file sconosciuti per vedere cosa fanno. Usa gli hash, apri il file in un visualizzatore di testo o leggi la documentazione. L'esecuzione va fatta in un laboratorio controllato, e non sul computer di tutti i giorni.

#Come andare oltre

Quando hai due ruoli sulla scheda, leggi nello strumento della CISA le descrizioni NICE di ciascuno. Alcuni ruoli rimandano anche alle micro-sfide di TryCyber, piccoli esercizi pratici sui compiti di base. Poi segui gli articoli del Manuale da campo nell'ordine indicato per il tuo primo ruolo. Dopo un mese riprendi la scheda e aggiornala con quello che hai fatto davvero.

Se chiedi a un assistente AI di spiegarti una riga di log o un frammento di codice, controlla la risposta sulla documentazione ufficiale di quell'evento o linguaggio. Una spiegazione è un punto di partenza per le tue letture, e non una fonte.

Questo Manuale da campo è pubblicato da NotHoly. Nessuno dei passi precedenti richiede un account NotHoly o un assistente AI.

#Fonti

• NIST, NICE Framework Resource Center: https://www.nist.gov/itl/applied-cybersecurity/nice/nice-framework-resource-center
• NIST, SP 800-181 Revision 1, Workforce Framework for Cybersecurity (NICE Framework): https://csrc.nist.gov/pubs/sp/800/181/r1/final
• CISA, NICCS Cyber Career Pathways Tool: https://niccs.cisa.gov/workforce-development/cyber-career-pathways-tool