Introduzione

La discussione immortale
ovvero: il reboot che nessuno vuole fare

C’è una conversazione che non muore mai. Non importa quante tecnologie cambino, quante certificazioni nascano o quante slide con sfondi blu vengano proiettate in qualche conferenza con nomi altisonanti. Lei torna. Sempre.

Di solito inizia così:

“Ma scusa… se uno è un grande sviluppatore o un sistemista senior, non è automaticamente pronto per fare sicurezza?”

E lì capisco che siamo di nuovo al punto zero.

Sono trent’anni che sento questa domanda. Trent’anni. Cambiano i nomi: ieri era COM+, poi .NET, poi il cloud, poi DevSecOps, oggi l’AI. Ma il copione è sempre lo stesso, con una coerenza narrativa che farebbe invidia a una serie TV di successo.

La risposta breve sarebbe: no.
Quella lunga è: dipende, ma quasi sempre no.

Non perché manchino intelligenza o competenze tecniche. Anzi. Ho lavorato con sviluppatori che scrivevano codice come se fosse poesia e sistemisti capaci di tenere in piedi infrastrutture che sembravano progettate da un comitato di entità caotiche.

Il problema non è la bravura.

Il problema è pensare che la sicurezza dell'informazione sia una naturale estensione di qualcos’altro. Come se fosse il livello bonus dopo aver completato il gioco principale.

Spoiler: non è così.

Perché non la chiamo cybersecurity (e no, non è snobismo)

Prima di andare avanti, chiariamo una cosa: userò deliberatamente il termine sicurezza dell'informazione.

Non cybersecurity.

Non perché non mi piaccia la parola, ma perché è diventata una specie di ombrello sotto cui si infila qualsiasi cosa abbia una tastiera. Cybersecurity è il sottodominio più rumoroso, quello che finisce nei titoli dei giornali quando qualcuno scopre improvvisamente che Internet esiste.

La sicurezza dell'informazione è più ampia. Molto più ampia.

Include tecnologia, certo. Ma anche regolamenti, processi, responsabilità legale, gestione del rischio, cultura organizzativa e una buona dose di realismo umano.

E qui nasce il primo grande equivoco: pensare che basti essere molto tecnici per capire la sicurezza.

No.

Essere competenti in un dominio non significa automaticamente comprendere la complessità della sicurezza dell'informazione. Anzi, a volte succede il contrario: più sei profondo in un’area, più rischi di vedere il mondo solo attraverso quella lente.

E sì, Dunning-Kruger e Schopenhauer non erano lì per decorare slide motivazionali.

Mondadori Informatica, l’aula e il laboratorio umano

Se c’è una cosa che la mia storia professionale mi ha regalato è stato un osservatorio privilegiato sul comportamento umano applicato alla tecnologia.

In Mondadori Informatica, tra marketing e formazione come MCT, mi sono ritrovato in mezzo a due tribù tecniche che parlavano lingue simili ma pensavano in modo completamente diverso: sviluppatori e sistemisti.

Entrambi convinti di avere il controllo.
Entrambi tecnicamente preparati.
Entrambi allergici all’idea che la sicurezza fosse una disciplina separata.

E così mi trovavo spesso a fare una cosa curiosa: non insegnare una tecnologia, ma costringere le persone a cambiare prospettiva.

Perché il punto non era spiegare dove cliccare.

Il punto era spiegare perché non cliccare.

La sicurezza non nasce spontaneamente da un wizard. E neppure da una pipeline moderna con un nome elegante.

Serve qualcuno che faccia domande scomode.

Tipo:

cosa succede se qualcuno usa questa cosa nel modo peggiore possibile?

Quella domanda non era popolare.

Il mito del talento tecnico come passaporto universale

Ogni epoca ha avuto il suo eroe tecnologico.

Lo sviluppatore salvava il mondo.
Poi il sistemista.
Poi il DevOps.
Adesso l’AI engineer.

E ogni volta qualcuno dice:

“Questa figura capirà anche la sicurezza.”

No.

Essere un grande sviluppatore significa costruire sistemi complessi.
Essere un grande sistemista significa mantenerli operativi.
Fare sicurezza significa immaginare come distruggerli creativamente.

Sono tre mestieri diversi.

E non è una questione di ego. È una questione di modello mentale.

Lo sviluppatore vede funzionalità.
Il sistemista vede stabilità.
Chi fa sicurezza vede abuso potenziale.

Quando queste visioni non si parlano, nascono architetture meravigliose… fino al giorno in cui qualcuno decide di giocare sporco.

Il vero problema non è tecnico. È cognitivo.

Molti pensano che il conflitto tra IT, sviluppo e sicurezza sia una guerra di ruoli.

In realtà è una guerra di prospettive.

La sicurezza dell'informazione vive di domande che agli altri sembrano inutilmente pessimiste:

• • serve davvero questo privilegio?
  • cosa succede se questa identità viene abusata?
  • perché questa password non può essere cambiata?
  • chi ha deciso che questo requisito è “normale”?

Non sono domande tecniche. Sono domande cognitive.

E senza quel tipo di mentalità, puoi avere tutte le piattaforme secure-by-default del mondo… e continuare a costruire sistemi fragili.

Perché continuo a parlarne dopo trent’anni

Potrei limitarmi a osservare il dibattito da lontano. Mettere like ironici, scrivere commenti criptici e tornare a leggere regolamenti europei per hobby, come una persona perfettamente equilibrata.

E invece continuo a raccontare questa storia.

Perché oggi la complessità è aumentata in modo esponenziale.

Non ci sono più solo sviluppatori e sistemisti.

Ci sono ethical hacker, architetti cloud, AI engineer, CEO che improvvisamente scoprono la sicurezza dopo un incidente e CFO che chiedono se il rischio può essere ammortizzato fiscalmente.

Il perimetro si è allargato.
La confusione pure.

Questa serie non è un manuale. È una memory lane sarcastica, un viaggio tra ieri, oggi e domani per spiegare perché continuo a ripetere una frase che ormai suona come un disco rotto:

La sicurezza non è sviluppo.
La sicurezza non è IT.
La sicurezza è un mestiere diverso.

E sì, se non lo sai… sallo.

IERI

Quando COM+, .NET e il privilegio amministrativo erano considerati uno stile di vita

Ovvero: l’epoca in cui la sicurezza esisteva già… ma nessuno aveva tempo di usarla

Se oggi qualcuno mi dice che “una volta era tutto più semplice”, io annuisco con lo stesso entusiasmo con cui si annuisce a chi sostiene che i floppy disk fossero più affidabili del cloud.

No. Non era più semplice.
Era solo meno visibile.

Negli anni in cui COM+ e poi .NET iniziavano a promettere ordine nel caos, si respirava un entusiasmo quasi mistico. Finalmente modelli strutturati, identità gestite meglio, possibilità di separare privilegi e ruoli senza dover scrivere codice che sembrava un rituale arcano.

E io, ingenuamente, pensavo:

“Perfetto. Ora che gli strumenti ci sono, la sicurezza diventerà normale.”

Non è successo.

COM+, .NET e la grande illusione degli strumenti disponibili

Le piattaforme offrivano già allora leve importanti: autenticazione, impersonation, controlli granulari, gestione dei privilegi. Non erano perfette, ma erano più che sufficienti per evitare certe… come dire… creatività architetturali.

Il problema non era la mancanza di tecnologia.

Il problema era l’idea diffusa che la sicurezza fosse un accessorio opzionale, da installare solo se richiesto dal committente o se qualche audit minacciava di trasformarsi in un romanzo horror.

Ricordo discussioni con sviluppatori preparatissimi, persone capaci di risolvere bug complessi in pochi minuti, che però davanti al tema sicurezza diventavano improvvisamente pragmatici fino al cinismo:

“Se non lo chiede il cliente, perché complicarsi la vita?”

Una frase semplice. Lineare. Economicamente razionale.

Ed è lì che capisci che la sicurezza dell'informazione non è una questione tecnica. È una questione culturale.

Perché nessun cliente chiede esplicitamente che le fondamenta della casa siano solide. Lo dà per scontato. Finché la casa non decide di testare la gravità.

Il gestionale che voleva l’admin come coinquilino fisso

Uno dei miei ricordi preferiti, nel senso clinico del termine, riguarda applicazioni gestionali scritte in VB che sembravano avere una relazione affettiva con i privilegi amministrativi.

Non bastava essere admin.
Bisognava essere loggati come admin sul server.

Non per installare.
Non per configurare.
Per lavorare.

Quando chiedevo il perché, le risposte erano sempre meravigliosamente sincere:

“Scrive in quella cartella.”
“Serve per registrare un componente.”
“Così funziona.”

È incredibile come la parola “funziona” riesca a giustificare qualsiasi cosa. È la versione tecnica di “fidati di me”.

Quello che cercavo di spiegare non era una regola astratta. Era una semplice osservazione: quando l’admin diventa un requisito funzionale, non stai semplificando. Stai spostando il problema nel futuro, dove qualcuno lo pagherà con interessi.

Ma in quell’epoca l’obiettivo era consegnare software che partisse. Non software che sopravvivesse.

La conferenza da 1500 persone e il blackhole che fece vacillare la fede

Uno dei momenti più surreali della mia vita professionale avvenne durante una Windows Professional Conference in Italia. Sala enorme, circa millecinquecento persone. Non principianti: professionisti esperti, gente che viveva dentro i server.

Io parlavo del firewall Microsoft di allora, Internet Security and Acceleration Server. Firewall, reverse proxy, pubblicazione servizi… insomma, roba seria.

A un certo punto introduco il concetto di blackhole IP.

Idea semplice: traffico indesiderato? Non rispondere. Non negoziare. Non loggare all’infinito. Mandalo nel nulla e vai avanti.

Una misura di igiene operativa.

E lì succede qualcosa di affascinante.

Metà sala annuisce con aria soddisfatta.
L’altra metà sembra aver appena sentito un’eresia.

Alcuni vedevano mitigazione intelligente.
Altri pensavano stessi suggerendo di ignorare il problema.

In quel momento ho capito che la sicurezza non è mai solo tecnologia. È interpretazione.

Per qualcuno bloccare è proteggere.
Per altri bloccare è nascondere.

La differenza non stava nella competenza tecnica. Stava nella mentalità.

Sistemisti e la domanda proibita: “cosa ti serve davvero?”

Se con gli sviluppatori combattevo la guerra dei privilegi, con i sistemisti affrontavo una sfida diversa: l’inventario.

Domanda semplice: quali servizi servono davvero su questo server?

Silenzio.

Non perché non sapessero fare il loro lavoro. Ma perché quella domanda implicava una responsabilità enorme: decidere cosa togliere.

E togliere è sempre più difficile che aggiungere.

Ricordo infrastrutture dove tutto restava acceso perché “non si sa mai”. Server che diventavano collezioni di funzionalità ereditate da progetti dimenticati, patchate, aggiornate, ma mai davvero comprese.

Senza inventario non esiste hardening.
Senza hardening non esiste perimetro.
Senza perimetro… beh, chiamiamolo hobby tecnologico avanzato.

Active Directory: quando la cassaforte diventa il bancone

Un’altra perla dell’epoca era l’architettura “creativa” di Active Directory.

Domain Controller usati anche come web server esposti su Internet.

Perché? Perché era comodo. Perché c’era già la macchina. Perché “tanto è protetto”.

È difficile spiegare quanto sia surreale vedere l’identità aziendale e la superficie pubblica condividere lo stesso spazio, come se fosse la cosa più naturale del mondo.

È un po’ come usare la cassaforte come tavolino da bar: funziona… finché qualcuno decide di aprirla.

Segreti embedded e utenti immortali

E poi c’era il capitolo delle credenziali.

Password hardcoded.
Chiavi di autenticazione impossibili da cambiare.
Account inamovibili perché altrimenti l’applicazione entrava in crisi esistenziale.

Quando chiedevo perché non ruotare le credenziali, la risposta era spesso accompagnata da uno sguardo preoccupato:

“Meglio non toccare. Funziona.”

La sicurezza, in quel contesto, era vista come una forza destabilizzante. Qualcosa che rischiava di rompere un equilibrio fragile.

E così i segreti diventavano permanenti. Non perché fosse una buona idea, ma perché nessuno voleva essere quello che aveva rotto tutto.

Il vero denominatore comune: la sicurezza come optional

Guardando indietro, quello che unisce tutti questi episodi non è la tecnologia. È la percezione della responsabilità.

Gli sviluppatori pensavano che la sicurezza fosse infrastruttura.
I sistemisti pensavano che fosse sviluppo.
I manager pensavano che fosse compliance.

E la sicurezza dell'informazione rimaneva sospesa nel mezzo, come un parente scomodo alle riunioni di famiglia.

Gli strumenti esistevano.
Le piattaforme evolvevano.
Ma senza un cambio di mentalità restavano solo possibilità teoriche.

E forse è proprio questa la lezione più ironica dell’epoca: non mancava la tecnologia. Mancava qualcuno disposto a fare la domanda più semplice e più scomoda di tutte:

“E se qualcuno provasse a usare questa cosa contro di noi?”

OGGI

Secure-by-default, YAML copiati da StackOverflow e altre religioni contemporanee

Ovvero: cambiano le tecnologie, ma l’idea che “la sicurezza la farà qualcun altro” resta sorprendentemente stabile

Non sono più in aula come una volta. Non passo le giornate davanti a classi con lo sguardo tra il curioso e il rassegnato mentre cerco di spiegare perché l’admin non dovrebbe essere uno stile di vita.

Eppure faccio ancora lo stesso mestiere.

Cerco di lavorare sulla sicurezza dell'informazione e, soprattutto, di spiegare perché esiste. Che è una cosa diversa dal configurare strumenti. Molto diversa.

Oggi il contesto è cambiato radicalmente. Non si parla più di COM+ o delle impostazioni obscure di .NET. Le conversazioni ruotano attorno a cloud, container, pipeline, identità distribuite, zero trust e, naturalmente, Intelligenza Artificiale.

Eppure, sotto tutta questa modernità, continuo a vedere schemi che conosco fin troppo bene.

La nuova fede: “secure by default”

Negli ultimi anni è nata una frase che sembra avere proprietà calmanti universali:

“Tranquilli, è secure by default.”

Una frase meravigliosa. Elegante. Quasi terapeutica.

Il problema è che secure by default non significa secure by design. E soprattutto non significa secure by thinking.

Le piattaforme moderne hanno davvero migliorato molte cose: cifratura automatica, autenticazione integrata, controlli che una volta richiedevano settimane di configurazione manuale. È un progresso reale.

Ma la conseguenza inattesa è che molti smettono di chiedersi cosa stanno proteggendo.

Ieri nessuno configurava le opzioni di sicurezza perché erano complicate.
Oggi nessuno le guarda perché sono automatiche.

Il risultato finale, curiosamente, può essere identico.

Dal wizard al pipeline: stessa storia, interfaccia diversa

Una volta si aprivano wizard pieni di checkbox misteriose. Oggi si copiano file YAML da repository che nessuno legge davvero.

Prima si concedevano privilegi amministrativi perché “altrimenti non parte”.
Oggi si assegnano permessi eccessivi a identità cloud perché “lo richiede il deployment”.

Prima avevamo applicazioni con admin locale.
Adesso abbiamo container privilegiati che fanno cose che nemmeno loro sanno spiegare.

La tecnologia cambia.
Le scorciatoie mentali restano.

E il paradosso è quasi poetico: più le piattaforme diventano sicure di default, più cresce la tentazione di smettere di pensare alla sicurezza come disciplina.

Gli ethical hacker: necessari, utili, ma non la soluzione universale

Negli ultimi anni è esplosa la figura dell’ethical hacker.

Persone competenti, spesso brillantissime, capaci di trovare vulnerabilità dove altri vedono solo codice funzionante. Sono fondamentali. Senza di loro molte organizzazioni vivrebbero ancora nell’illusione della perfezione.

Ma c’è un equivoco che continua a riaffiorare: l’idea che trovare bug equivalga a fare sicurezza.

No.

Un ethical hacker trova una falla.
Un professionista della sicurezza dell'informazione dovrebbe chiedersi perché quella falla era inevitabile.

Il bug è il sintomo.
La sicurezza è il contesto.

Eppure vedo aziende convinte che basti un penetration test annuale per dormire tranquille. È la versione moderna del firewall miracoloso degli anni 2000: comprare uno strumento e sperare che risolva un problema culturale.

Non funziona così. Non ha mai funzionato così.

Il codice è migliore, le architetture… dipende

Una cosa va detta: oggi molti sviluppatori hanno una sensibilità maggiore rispetto al passato. Le librerie sono migliori, i framework integrano controlli che un tempo erano fantascienza, gli ambienti di sviluppo segnalano vulnerabilità prima ancora che tu finisca di scrivere una funzione.

Eppure continuo a vedere codice tecnicamente impeccabile inserito in contesti architetturali fragili.

API esposte senza un vero modello di autorizzazione.
Identità applicative con privilegi eccessivi.
Segreti gestiti come variabili d’ambiente dimenticate lì “per comodità”.

Non è incompetenza. È una diversa priorità.

Lo sviluppo guarda alla funzionalità.
La sicurezza guarda all’abuso.

Due prospettive che raramente coincidono senza un ponte cognitivo.

Il cloud ha reso tutto più semplice. Anche sbagliare.

Se negli anni passati chiedevo ai sistemisti quali servizi servissero davvero su un server, oggi faccio una domanda simile a chi progetta ambienti cloud:

“Quali identità sono davvero necessarie?”
“Quali permessi possiamo togliere senza rompere tutto?”

La risposta è spesso la stessa di vent’anni fa, solo con parole più moderne:

“Meglio lasciare tutto così… non si sa mai.”

Il cloud ha democratizzato l’accesso alla tecnologia. Ha reso possibile creare infrastrutture complesse con pochi click. Ma ha anche moltiplicato le possibilità di errore.

Oggi puoi costruire un sistema globale in un pomeriggio.
Puoi anche esporlo accidentalmente al mondo intero nello stesso tempo.

E qui torna il punto centrale: la sicurezza dell'informazione non nasce dalla velocità con cui distribuisci qualcosa, ma dalla consapevolezza con cui decidi cosa distribuire.

L’Intelligenza Artificiale come nuovo oracolo

E poi è arrivata l’AI, con la promessa di rendere tutto più intelligente.

Analizza log.
Segnala anomalie.
Scrive codice.
Propone remediation.

Ed ecco riemergere la narrativa familiare: “Adesso la sicurezza sarà automatica.”

La verità è più sobria.

Un modello può suggerire una soluzione.
Non può decidere quale rischio accettare.

Non può comprendere il contesto organizzativo, la pressione del mercato, le implicazioni legali, le conseguenze reputazionali.

Può accelerare decisioni. Non sostituirle.

E qui ritorna il filo rosso che collega ieri e oggi: ogni nuova tecnologia viene vista come la risposta definitiva. Finché non scopriamo che la domanda era sbagliata.

Io continuo a fare lo stesso mestiere

A volte mi chiedono cosa significhi oggi lavorare nella sicurezza dell'informazione.

La risposta è meno tecnica di quanto ci si aspetti.

Significa parlare con sviluppatori senza diventare sviluppatore.
Con sistemisti senza diventare sistemista.
Con ethical hacker senza diventare hacker tecnico.

È un lavoro di traduzione continua.

E oggi, più che mai, significa ricordare a tutti che la sicurezza non è una funzione accessoria da delegare a uno strumento o a un ruolo specifico.

È una disciplina che vive tra i confini.

E i confini, nel mondo moderno, sono diventati molto più affollati.

DOMANI

L’AI non diventerà il vostro CISO (e altre profezie tecnologiche che suonano bene nelle slide)

Ovvero: il futuro sarà velocissimo, ma continuerà a inciampare sugli stessi errori cognitivi

Se c’è una cosa che ho imparato in questi anni è che ogni generazione tecnologica arriva accompagnata da una promessa implicita: questa volta sarà diverso.

Con COM+ si pensava che l’architettura avrebbe imposto ordine.
Con .NET che il managed code avrebbe reso tutto più sicuro.
Con il cloud che l’automazione avrebbe eliminato gli errori umani.
Oggi l’Intelligenza Artificiale promette di fare da babysitter alla sicurezza.

E ogni volta io mi ritrovo a pensare la stessa cosa: non è la tecnologia che sbaglia. È l’aspettativa che ci costruiamo sopra.

Perché il futuro non eliminerà la responsabilità. La amplificherà.

L’illusione della sicurezza automatica

Oggi vedo molte organizzazioni convinte che l’AI possa finalmente chiudere il cerchio.

“Analizza i log.”
“Classifica le anomalie.”
“Blocca comportamenti sospetti.”

E tutto questo è vero. L’AI accelera. Migliora. Riduce il rumore.

Ma c’è una cosa che non può fare: decidere cosa è accettabile per la tua organizzazione.

Un modello può dire che qualcosa è anomalo.
Non può sapere se quella anomalia è un rischio accettabile o una catastrofe strategica.

La sicurezza dell'informazione non è solo rilevare. È decidere.

E decidere significa assumersi responsabilità che nessun algoritmo potrà mai firmare.

La prossima confusione: AI engineer uguale esperto di sicurezza?

Negli ultimi tempi vedo emergere una nuova figura professionale con l’aura che un tempo avevano gli architetti .NET o gli evangelist cloud: l’AI engineer.

Professionisti competenti, immersi in modelli, dataset, pipeline, prompt e ottimizzazioni che farebbero girare la testa a chiunque abbia ancora nostalgia dei batch file.

E già sento la stessa domanda di vent’anni fa, solo aggiornata:

“Se uno costruisce sistemi AI complessi… non è già pronto per fare sicurezza?”

La risposta è familiare.

No.

Non perché manchi competenza tecnica. Ma perché sviluppare un sistema e immaginare come possa essere abusato sono due attività cognitive diverse.

Chi costruisce pensa a come far funzionare qualcosa.
Chi fa sicurezza pensa a come qualcuno potrebbe usarla nel modo peggiore possibile.

Sono due prospettive complementari. Non intercambiabili.

Dal bug al comportamento emergente

Nel futuro prossimo la sicurezza non parlerà sempre meno di bug isolati e sempre più di comportamenti emergenti.

Non sarà solo una questione di codice sbagliato. Sarà una questione di sistemi complessi che reagiscono in modi inattesi.

Un modello AI che amplifica bias.
Una pipeline automatica che distribuisce errori più velocemente di quanto possiamo fermarli.
Un ecosistema di identità digitali che interagiscono senza una vera supervisione umana.

Il rischio non sarà solo tecnico. Sarà sistemico.

E qui la sicurezza dell'informazione tornerà a essere quello che è sempre stata: la disciplina che prova a capire il significato delle cose, non solo il loro funzionamento.

Il futuro non semplificherà. Renderà tutto più ambiguo.

Molti immaginano un domani dove gli strumenti saranno così intelligenti da eliminare la complessità.

Io vedo qualcosa di diverso.

Vedo un mondo dove le decisioni saranno prese sempre più velocemente, con meno tempo per riflettere. Dove i ruoli si mescoleranno: sviluppatori che gestiscono infrastrutture, manager che parlano di modelli AI, CFO che improvvisamente scoprono cosa sia la resilienza operativa.

La complessità non sparirà.

Diventerà invisibile.

Ed è proprio l’invisibilità che rende le cose pericolose.

Perché quando tutto sembra funzionare perfettamente, nessuno sente il bisogno di fare le domande scomode.

Il mestiere più strano del futuro: tradurre mondi diversi

Se guardo avanti, immagino che il lavoro di chi si occupa di sicurezza dell'informazione sarà sempre meno tecnico nel senso tradizionale e sempre più cognitivo.

Non servirà sapere tutto.
Servirà capire abbastanza per fare da ponte.

Tra sviluppatori e legali.
Tra sistemisti e manager.
Tra AI engineer e responsabili del rischio.

La sicurezza non sarà la disciplina di chi sa più cose. Sarà la disciplina di chi sa collegare prospettive diverse senza farsi ingannare dall’illusione di semplicità.

E sì, continueremo a essere percepiti come quelli che fanno domande fastidiose mentre tutti cercano di andare più veloci.

È un ruolo poco glamour, ma qualcuno deve pur farlo.

Domani non sarà diverso. Sarà solo più veloce.

La vera differenza tra ieri, oggi e domani non è la tecnologia.

È la velocità con cui gli stessi errori cognitivi riescono a reinventarsi con un nome nuovo.

Ieri era l’admin locale.
Oggi è l’identità con permessi eccessivi.
Domani sarà probabilmente un agente AI con troppa autonomia.

Cambieranno gli strumenti.
Non cambierà la necessità di qualcuno che si fermi e dica:

“Ok, ma cosa succede se questo sistema viene usato contro di noi?”

Ed è per questo che, anche nel futuro più automatizzato possibile, la sicurezza dell'informazione resterà un mestiere umano.

Un mestiere fatto più di domande che di risposte.

CONCLUSIONE

L’arte sottovalutata di non sapere tutto (e continuare comunque a fare sicurezza)

Ovvero: se pensi di aver capito tutto, probabilmente hai appena iniziato a capire meno

C’è una cosa che raramente viene detta ad alta voce, forse perché suona poco eroica, poco vendibile e decisamente poco adatta a una bio LinkedIn piena di acronimi:

Chi si occupa di sicurezza dell'informazione non sa tutto.
E soprattutto… non deve saperlo.

Sembra una debolezza. In realtà è una forma di igiene mentale.

Negli anni ho sviluppato passioni molto specifiche, a volte perfino ostinate: regolamenti, legaltech, data protection, privacy, sicurezza informatica. Non perché voglia diventare un’enciclopedia ambulante, ma perché questi domini raccontano come la tecnologia impatta davvero le organizzazioni e le persone.

Ma più approfondisci un ambito, più diventa evidente una verità poco glamour: pretendere di sapere tutto è il modo più veloce per sapere male.

Ed è qui che entrano in scena due personaggi che non hanno mai scritto una riga di codice, ma continuano a spiegare meglio di molti manuali cosa succede quando la sicurezza viene trattata con superficialità: Dunning-Kruger e Schopenhauer.

Il primo ci ricorda quanto sia facile sopravvalutare la propria comprensione.
Il secondo ci avverte che la nostra percezione del mondo è sempre filtrata, incompleta, inevitabilmente limitata.

Tradotto nel linguaggio quotidiano della sicurezza: più credi di avere il quadro completo, più rischi di non vedere quello che conta davvero.

Non sono molte cose. Ed è proprio il punto.

Non sono un IT manager.
Non sono uno sviluppatore.
Non sono un technical hacker.

Eppure devo poter parlare con tutti loro.

Devo capire abbastanza di sviluppo per non dire sciocchezze.
Abbastanza di infrastruttura per non chiedere l’impossibile.
Abbastanza di hacking tecnico per non confondere un sintomo con una causa.

La sicurezza dell'informazione è un mestiere di traduzione continua.

Non consiste nel diventare tutto.
Consiste nel collegare tutto.

E questa è forse la parte più fraintesa del ruolo: non è una disciplina che vive sopra le altre, ma tra le altre.

Tra sviluppo e governance.
Tra infrastruttura e normativa.
Tra tecnologia e responsabilità.

Il framework cognitivo che ancora non abbiamo (ma ci serve disperatamente)

Se c’è una cosa che ieri, oggi e domani continuano a insegnarmi è che il vero problema non è la mancanza di strumenti.

È la mancanza di un framework cognitivo comune.

Sviluppatori, sistemisti, ethical hacker, architetti cloud, AI engineer… ognuno parla il proprio linguaggio tecnico, con priorità diverse e metriche diverse.

E oggi al tavolo non siedono più solo figure tecniche.

Ci sono CEO che devono decidere cosa significa accettare un rischio.
CFO che vogliono capire l’impatto economico di un incidente.
Legal e compliance che trasformano decisioni tecniche in responsabilità legali.

La sicurezza dell'informazione è diventata una conversazione multidisciplinare.

Eppure spesso continuiamo a trattarla come se fosse un problema tecnico confinato in un reparto.

Non lo è più da tempo.

La complessità cresce. Ignorarla non la rende più semplice.

Ieri bastava distinguere tra sviluppo e infrastruttura.

Oggi dobbiamo gestire identità distribuite, supply chain software, AI, normative che cambiano più velocemente delle architetture e decisioni che coinvolgono livelli aziendali sempre più alti.

Domani sarà ancora più complicato.

Chi non vede questa complessità non è necessariamente in mala fede. Ma rischia di essere cieco.

Perché la sicurezza non fallisce quando qualcosa è difficile. Fallisce quando qualcuno decide che non è così difficile.

La vera maturità non sta nel dire “so tutto”.
Sta nel dire “so abbastanza per capire cosa non so”.

Ieri, oggi, domani: il filo rosso

Guardando indietro, mi accorgo che la tecnologia è cambiata continuamente. I nomi delle piattaforme, gli strumenti, le mode professionali… tutto si è trasformato.

Ma il filo rosso è rimasto sorprendentemente stabile.

Ieri, la sicurezza veniva ignorata perché rallentava lo sviluppo.
Oggi viene delegata agli strumenti perché sembrano intelligenti.
Domani rischia di essere affidata a sistemi automatici perché promettono di semplificare.

E ogni volta qualcuno deve ricordare che la sicurezza dell'informazione non è una feature, non è un ruolo isolato e non è una competenza che nasce per osmosi.

È un modo di pensare.

Un modo di guardare sistemi complessi e chiedersi cosa succede quando qualcosa va storto… e quando qualcuno prova deliberatamente a farlo andare storto.

Se non lo sai, sallo

Forse la lezione più importante, dopo trent’anni, è questa:

La sicurezza non appartiene a una singola professione.
Non appartiene agli sviluppatori, né all’IT, né agli ethical hacker, né agli executive.

Appartiene al dialogo tra loro.

E chi lavora nella sicurezza dell'informazione non è quello che sa tutto. È quello che continua a fare domande quando gli altri pensano di aver già capito.

Ieri, oggi, domani.

Se non lo sai… sallo.