Dietro le quinte
Perché ho creato un corso di cybersecurity
Guida pratica per iniziare: passi concreti e risorse utili.
Il problema che vedevo ogni settimana: tanta teoria, poca “pelle in gioco”
Ho creato un corso di cybersecurity dopo aver visto lo stesso schema ripetersi: persone motivate, ore di video e appunti, ma al primo esercizio pratico si bloccano. Non perché “non siano portate”, ma perché spesso hanno studiato concetti scollegati dall’operatività. Nella pratica, quando apri un log, un ticket o una traccia di laboratorio, non c’è un capitolo 1-2-3: devi capire cosa guardare, in che ordine, e cosa significa davvero.
Capita spesso anche ai colloqui junior: qualcuno sa spiegare cos’è un firewall, ma non sa leggere una regola e capire se sta facendo passare troppo. Oppure conosce le definizioni di phishing e MFA, però non sa ricostruire la catena di un attacco da una mailbox compromessa. La distanza tra “so la teoria” e “riesco a lavorarci” è il motivo principale per cui ho deciso di costruire un percorso diverso.
Perché un percorso strutturato vale più di 100 risorse sparse
Una domanda frequente è: “Non posso fare tutto da YouTube e dai blog?” Dipende: se hai già un metodo, sai scegliere le fonti, e soprattutto sai progettarti esercizi e verifiche, sì, è possibile. Il problema è che molti partono da zero e si ritrovano con dieci tab aperti, tre roadmap diverse e nessun criterio per capire se stanno migliorando.
Un corso di cybersecurity ha senso quando ti dà una sequenza chiara: prima le basi giuste, poi i lab, poi la capacità di spiegare quello che hai fatto. Il punto non è “studiare di più”, ma evitare sprechi: settimane su argomenti troppo avanzati, oppure mesi su concetti generici senza mai sporcarsi le mani. Il mio obiettivo era proprio ridurre questa dispersione con una progressione che somiglia al modo in cui si lavora davvero.
Come ho progettato il corso: dal ticket al laboratorio, non dal glossario
Ho iniziato dal fondo: quali attività devono saper fare, in modo credibile, le persone che vogliono entrare in un team SOC, in un helpdesk con taglio security o in un ruolo junior di security operations. Da lì ho risalito i prerequisiti necessari. Non l’elenco infinito di “cose da sapere”, ma ciò che ti serve per non andare in crisi quando hai davanti un alert, un endpoint che comunica in modo strano o un accesso sospetto.
Nella pratica ho privilegiato casi d’uso ripetibili: leggere i log, correlare eventi, distinguere un falso positivo da un segnale reale, documentare una verifica. Molti si chiedono se “serva saper programmare”: spesso aiuta, ma all’inizio conta di più saper ragionare su reti, sistemi e identità. E soprattutto imparare a produrre output: una nota tecnica, una timeline, una breve analisi con ipotesi e prossimi passi.
Il criterio guida: ogni modulo deve produrre un output verificabile
Se un contenuto non porta a qualcosa che puoi mostrare o ripetere, tende a rimanere astratto. Per questo ho impostato lezioni e lab in modo che ogni passaggio lasci traccia: screenshot ragionati, comandi eseguiti, log salvati, una breve relazione. È anche il modo più onesto per misurare il progresso: non “mi sembra di aver capito”, ma “sono riuscito a farlo e posso spiegarlo”.
Questo approccio riduce un errore tipico dei profili junior: collezionare concetti senza saperli applicare. Ai colloqui si vede subito, perché basta una domanda del tipo “cosa controlleresti per primo?” per far emergere se hai un metodo o solo nozioni.
La sequenza pratica che consiglio: cosa fare prima, cosa dopo
Uno dei motivi per cui ho creato il percorso è che l’ordine conta. Non ha senso partire da malware analysis se non sai interpretare una connessione di rete, e non ha senso parlare di incident response se non sai raccogliere evidenze minime. Qui sotto trovi una sequenza che uso spesso anche per orientare chi arriva da percorsi diversi e vuole capire cosa mettere in fila.
Non è una “ricetta universale”, ma un modo realistico per evitare di saltare passaggi. Se segui la logica, ti accorgi presto dove hai buchi: e quei buchi, in cybersecurity, poi si pagano quando devi decidere in fretta e con poche informazioni.
| Step | Cosa fare | Output |
|---|---|---|
| 1 | Mettere ordine su networking, DNS, HTTP, autenticazione | Note operative + esercizi ripetuti (comandi, test, verifiche) |
| 2 | Imparare a leggere log e telemetria (endpoint, web, accessi) | Mini analisi: cosa è normale vs sospetto, con esempi salvati |
| 3 | Eseguire lab guidati su scenari comuni (phishing, account takeover, brute force) | Timeline dell’evento + ipotesi + controlli effettuati |
| 4 | Tradurre il lavoro in portfolio e linguaggio da colloquio | 1–2 case study scritti in modo chiaro e difendibile |
Gli errori che vedo più spesso nei profili junior (e che ho voluto evitare)
Il primo errore è inseguire certificazioni o argomenti “di tendenza” senza un filo: oggi cloud security, domani OSINT, poi pentest. Non c’è nulla di male a esplorare, ma se non costruisci fondamenta solide, ogni area diventa una collezione di tool. Al lavoro, invece, ti chiedono di capire cosa sta succedendo, non di ricordare il nome dell’ennesimo framework.
Il secondo errore è non saper documentare. Sembra banale, ma in un team serio la differenza tra un profilo acerbo e uno pronto spesso è la qualità degli appunti: cosa hai visto, cosa hai escluso, perché. Il terzo errore è confondere “hands-on” con “ho lanciato comandi”: se non sai spiegare il razionale, ai colloqui junior non regge. Per questo ho progettato esercizi in cui la parte importante non è il comando, ma la decisione che ci sta dietro.
Come capire se un corso fa per te: un criterio di scelta concreto (non marketing)
Quando valuti un percorso, il criterio che uso io è semplice: deve renderti capace di produrre evidenze e ragionamenti che un tecnico riconosce come sensati. Non “attestati”, non “ore di lezione”, ma materiali e processi. Se un corso non ti fa mai consegnare un output, non ti abitua a spiegare un’analisi e non ti espone a errori controllati (quelli che poi impari a correggere), di solito ti lascia con una sicurezza fragile.
Se vuoi un riferimento più dettagliato su come valutare programmi e promesse, ho messo nero su bianco i criteri che uso in https://academycybersecurity.it/blog/come-scegliere-corso-cybersecurity-italia/. Leggilo con spirito critico: l’obiettivo non è “trovare il corso perfetto”, ma evitare di investire tempo e soldi in un percorso che non ti porta a fare, davvero.
- Riesci a vedere esempi di output reali (report, timeline, analisi) e non solo il programma?
- Ci sono esercizi in cui devi motivare le scelte (cosa controlli prima e perché)?
- Il corso esplicita prerequisiti e livello di partenza, senza vaghezze?
- È chiaro come si misura il progresso (prove pratiche, consegne, revisioni)?
- Viene trattata la documentazione tecnica: note, ticket, handover?
- È spiegato quali ruoli junior copre e quali no, con esempi di attività quotidiane?
Da dove partire se sei a zero (e cosa aspettarti realisticamente)
Molti arrivano con l’idea di “entrare in cybersecurity” come se fosse un unico lavoro. In realtà è un insieme di ruoli: SOC, GRC, security engineering, application security, cloud, incident response. Cambiano linguaggio, strumenti e priorità. Se sei a zero, di solito conviene partire dalle competenze trasversali: reti, sistemi, identità, logica di troubleshooting. È la base che ti permette poi di specializzarti senza dover ricominciare ogni volta.
Se ti serve una traccia concreta per muovere i primi passi senza esperienza, in https://academycybersecurity.it/blog/entrare-in-cybersecurity-senza-esperienza/ trovi un percorso ragionato. Non è una scorciatoia: è un modo per impostare aspettative sane e capire quali progetti fare per diventare credibile. Una domanda frequente è “quanto ci metto?”: dipende dal tempo che puoi dedicare e dal tuo background, ma l’indicatore migliore è la qualità degli output che riesci a produrre, non il numero di ore studiate.
Il dietro le quinte della scelta: creare un percorso che regga ai colloqui
Quando ho costruito questo corso di cybersecurity, avevo in mente un momento preciso: il colloquio tecnico junior in cui ti chiedono di raccontare un caso, non di ripetere definizioni. Se non hai mai scritto una mini analisi o non hai mai ragionato su un log, ti trovi a improvvisare. E improvvisare, in un contesto tecnico, si sente: mancano priorità, mancano ipotesi, manca il “perché” dietro ogni azione.
Per questo il percorso è pensato per farti arrivare con cose difendibili: piccoli casi studio, scelte motivate, tracce verificabili. Se poi vuoi vedere come ho strutturato l’Academy e cosa include oggi, il punto di riferimento è https://academycybersecurity.it/. Non è per tutti: se cerchi solo teoria o solo tool, probabilmente ti sembrerà “lento”; se invece vuoi costruire metodo e risultati dimostrabili, ha più senso.
Se domani vuoi fare un passo concreto, scegline uno solo: o sistemi le basi (reti, DNS, autenticazione) con esercizi ripetibili, oppure prendi un caso semplice e lo documenti bene, come se dovessi passarlo a un collega. Da lì diventa molto più facile capire di cosa hai bisogno davvero, e decidere con lucidità se un percorso guidato è l’investimento giusto per te.
Se ti va di lavorare su un piano strutturato, puoi partire da https://academycybersecurity.it/ e confrontare il programma con la checklist qui sopra. L’idea non è convincerti: è metterti nelle condizioni di scegliere in modo informato, con aspettative realistiche e un ordine di studio che regge nella pratica.