Da aprile 2023 ricopro il ruolo di IT Manager e Responsabile della Sicurezza delle Informazioni (RSI). In questo articolo non racconto la teoria della cybersecurity aziendale — per quella ci sono libri e corsi. Racconto cosa ho fatto concretamente nei primi sei mesi, cosa ha funzionato e cosa ho dovuto rivedere.
Il punto di partenza: l'assessment iniziale
La prima cosa che ho fatto, prima di qualunque acquisto o implementazione, è stata mappare lo stato esistente. Non con uno strumento costoso: con interviste, analisi della documentazione disponibile e una checklist strutturata basata sui controlli del framework CIS (Center for Internet Security).
Il risultato dell'assessment ha rivelato tre categorie di problemi:
- Problemi immediati (rischio alto): patch management non strutturato, password policy inesistente, backup non verificati
- Problemi a medio termine (rischio medio): nessuna procedura di incident response, accessi privilegiati non monitorati, formazione assente
- Gap normativi: documentazione insufficiente per NIS2 e GDPR
"Il primo atto di un RSI non dovrebbe essere comprare un firewall nuovo: dovrebbe essere capire dove si trova l'azienda oggi. Solo dopo si decide cosa fare."
Mese 1-2: le basi non negoziabili
Ho iniziato dalle fondamenta, quelle che in sicurezza si chiamano cyber hygiene:
Patch management strutturato
Ho implementato un processo di aggiornamento sistematico per tutti i sistemi critici: inventario completo degli asset, classificazione per criticità, ciclo di patch mensile con verifica. Banale nella teoria, spesso trascurato nella pratica.
Password policy e MFA
Definita e implementata una password policy formale: complessità minima, rotazione, divieto di riutilizzo. Attivata l'autenticazione a più fattori su tutti gli accessi remoti e i sistemi critici. Resistenza iniziale degli utenti: prevista e gestita con formazione.
Backup verificati
Sorprendentemente, molti backup esistenti non venivano mai verificati. Ho implementato test di ripristino periodici: un backup che non si ripristina non è un backup.
Mese 3-4: procedure e incident response
La sicurezza non è solo tecnologia: è processo. Ho sviluppato tre documenti fondamentali che prima non esistevano:
Incident Response Plan
Un piano scritto che definisce: cosa costituisce un incidente, chi viene notificato, in quale ordine, con quali mezzi, e cosa fa ciascuno. Ho fatto anche un tabletop exercise con i responsabili di funzione: simulazione su carta di uno scenario di ransomware. È stato rivelatore — ogni partecipante aveva aspettative diverse su chi dovesse fare cosa.
Politiche di accesso e least privilege
Revisione completa degli accessi: chi ha accesso a cosa, perché, da quando. Molti accessi risalivano a ruoli che non esistevano più o a esigenze temporanee mai revocate. Rimozione sistematica di tutti gli accessi non più necessari.
Registro degli asset
Non si può proteggere ciò che non si conosce. Ho costruito un inventario completo: hardware, software, servizi cloud, dati critici. Con per ciascuno: responsabile, classificazione, posizione, stato degli aggiornamenti.
Mese 5-6: NIS2 e adeguamento normativo
La Direttiva NIS2 (D.Lgs. 138/2024) introduce obblighi significativi in Italia. Per la nostra organizzazione, l'adeguamento ha richiesto:
- Verifica dell'applicabilità: siamo in scope? Per quale categoria?
- Gap analysis rispetto ai requisiti minimi di sicurezza NIS2
- Nomina formale del RSI con documentazione delle responsabilità
- Definizione delle procedure di notifica degli incidenti (24h per notifica iniziale, 72h per notifica completa)
- Revisione dei contratti con i fornitori critici per includere clausole di sicurezza
Cosa ho imparato
La lezione più importante: la sicurezza è un processo continuo, non un progetto. Non si "implementa la sicurezza" e poi si passa ad altro. Si costruisce un sistema di monitoraggio, risposta e miglioramento continuo.
La seconda lezione: la tecnologia da sola non basta. Gli strumenti più sofisticati sono inutili se le persone non sanno come usarli o perché esistono. La formazione e la cultura della sicurezza sono altrettanto importanti dei firewall.
La terza: documentare tutto. Non per l'auditor — per te. Quando si verifica un incidente, avere procedure scritte e testate fa la differenza tra una risposta coordinata e il caos.