Sicurezza, Andropov e sciatteria di stato.
Quanto accaduto nel caso delle scuole evacuate ha fatto emergere un problema antico, al quale le grandi aziende private hanno trovato, nel corso degli anni, una sorta di “aggiustamento”, mentre la Pubblica Amministrazione non è ancora riuscita a superarlo. Si tratta del problema della sciatteria tecnica.
Cosa significa?
Significa che la PA italiana non ha ancora interiorizzato un concetto piuttosto semplice: ogni sciatteria tecnica è, in ultima analisi, una porta aperta a un attaccante esterno.
Lo abbiamo visto nel caso, quasi comico, delle scuole. Nello scorso post li ho presi in giro, e direi che se lo sono anche meritato. Ma adesso potrei provare a pensarci seriamente.
La prima cosa che salta agli occhi è la disomogeneità delle reazioni. Circa 6.300 scuole italiane hanno ricevuto la stessa comunicazione minatoria; il numero degli istituti che hanno poi proceduto all'evacuazione è stato invece molto più basso, nell'ordine delle centinaia o, secondo le ricostruzioni più aggiornate, oltre il migliaio. In ogni caso, non stiamo parlando di una risposta uniforme.
E qui casca l'asino, per la prima volta.
- tutte le scuole hanno ricevuto sostanzialmente lo stesso input: la minaccia firmata “Mikhail Andropov”;
- alcune scuole hanno evacuato;
- altre non hanno evacuato;
- in altre ancora la situazione è stata gestita in maniera intermedia, con verifiche e decisioni diverse a seconda del contesto.
Ora, questa differenza può essere perfettamente ragionevole se esiste un processo decisionale formalizzato che spiega perché, a parità di input, si arrivi a decisioni differenti.
Il problema nasce quando non abbiamo un processo, ma abbiamo semplicemente qualcuno che decide cosa fare.
Perché a quel punto la sicurezza non è più una proprietà del sistema. Diventa una proprietà della persona che, quella mattina, ha aperto la posta, ha letto la mail, ha valutato la situazione e ha deciso se chiamare la Polizia oppure far continuare le lezioni.
E questa è precisamente la differenza fra un'organizzazione che possiede una procedura di sicurezza e un'organizzazione che, quando succede qualcosa, si affida al buon senso di chi capita davanti al problema.
È assolutamente chiaro che i dirigenti scolastici hanno agito ognuno per conto proprio.
Una dirigente lombarda, per esempio, si è messa a investigare e ha scoperto che quel messaggio era già uno spam noto. Altri hanno evacuato. Altri ancora hanno aggiunto qualche pila di minchiate senza senso nelle interviste rilasciate ai giornali.
Il punto, però, è un altro.
In pratica, ora sappiamo che i dirigenti scolastici non hanno un piano operativo comune su come si agisce di fronte a una minaccia terroristica fisica rivolta contro l'edificio scolastico.
E questo è un problema tecnico, prima ancora che amministrativo.
Perché, se esiste una procedura comune, la minaccia arriva e la procedura viene applicata. Potrà anche prevedere margini di discrezionalità, naturalmente: non è che un dirigente debba diventare un automa. Ma deve esistere almeno una sequenza di azioni, responsabilità e criteri di valutazione condivisi.
Se invece non esiste, succede quello che abbiamo visto: la stessa minaccia entra contemporaneamente in migliaia di organizzazioni e produce migliaia di interpretazioni diverse.
Uno controlla il messaggio, uno evacua, uno chiama la Polizia, uno aspett, uno fa tutte queste cose insieme. E qualcuno, inevitabilmente, finisce davanti a un microfono a spiegare ai giornalisti qualcosa che probabilmente non avrebbe dovuto spiegare neppure a se stesso.
In altre parole, ognuno ha agito “a sentimento”.
E questa non è una battuta. È esattamente il tipo di problema organizzativo che, in un'azienda privata di una certa dimensione, viene normalmente affrontato con una procedura operativa.
Perché la procedura non serve quando tutto va bene.
Serve precisamente quando arriva qualcosa che nessuno vuole dover gestire alle nove del mattino, mentre l'organizzazione continua contemporaneamente a fare tutto il resto.
E questa mancanza di un piano ha uno nome: sciatteria.
Un altro problema che mi pongo è questo.
A quanto pare, quell'attacco era già stato identificato come spam/phishing a Taiwan, almeno a livello di segnalazioni e classificazioni pubbliche, diverse ore prima che arrivasse alle scuole italiane. Ora, non mi importa particolarmente che fosse Taiwan. Se usi una cosa come Microsoft Outlook Online, per esempio, ovunque succeda qualcosa, l'intero sistema ne prende atto.
Ed è probabilmente uno dei pochi vantaggi di usare un tenant inserito dentro un servizio globale: i problemi vengono affrontati a livello globale.
Se un certo account viene compromesso a Taiwan e da quell'account parte una campagna di posta anomala, il problema non dovrebbe rimanere confinato a Taiwan. Un sistema globale di posta elettronica vede milioni di messaggi e può correlare eventi che, presi singolarmente, sembrano irrilevanti.
E qui arriviamo al caso delle scuole italiane.
È chiaro che, per il suo contenuto, quel messaggio fosse assai più vicino allo spam che a una comunicazione normale. Era una minaccia generica, sproporzionata, scritta in un italiano quantomeno curioso, firmata da un'organizzazione inesistente e soprattutto inviata in massa a migliaia di destinatari.
Ora, se la scuola italiana, intesa come Ministero dell'Istruzione, utilizza un determinato provider per la posta elettronica, quel messaggio è entrato nel sistema migliaia di volte, sostanzialmente identico.
E qui la domanda diventa interessante.
Non sto dicendo che il filtro avrebbe necessariamente dovuto bloccarlo. Anzi: tecnicamente è perfettamente possibile che un messaggio proveniente da un account reale e compromesso superi i normali controlli di autenticità della posta. SPF, DKIM e DMARC possono dirti che il messaggio è autorizzato dal dominio mittente; non possono dirti che il legittimo proprietario dell'account lo abbia effettivamente spedito.
Ma proprio per questo esistono i sistemi antispam e antiphishing più sofisticati: non si limitano a guardare il mittente. Guardano il comportamento.
E allora la domanda sorge spontanea:
il Ministero dell'Istruzione aveva comprato, e correttamente configurato, qualche pacchetto di protezione dell'endpoint e della posta elettronica, antispam e antiphishing compresi?
Perché se la risposta è sì, allora sarebbe interessante capire che cosa sia successo.
E se la risposta è no, allora abbiamo finalmente trovato una manifestazione molto concreta della famosa sciatteria tecnica.
Perché una cosa è decidere da soli che una minaccia terroristica non è credibile.
Un'altra cosa è lasciare che la stessa identica mail venga consegnata migliaia di volte a migliaia di istituzioni pubbliche, senza che il sistema di posta dica almeno: ragazzi, questa cosa l'ho già vista.
I sistemi Microsoft possono farlo.
Addirittura scopriamo cose come questa: Trentino, Alto Adige e Valle d'Aosta sono rimasti fuori dall'ondata di minacce.
E qui c'è un fatto molto interessante: chiunque abbia collezionato gli indirizzi dei dirigenti scolastici sotto il dominio istruzione.it, a quanto pare, non si è messo a raccogliere anche gli indirizzi e-mail dei domini utilizzati da queste regioni autonome.
In particolare, le scuole altoatesine utilizzano indirizzi sotto i domini provincia.bz.it e provinz.bz.it, quelle trentine sotto provincia.tn.it, mentre in Valle d'Aosta viene utilizzato il dominio mail.scuole.vda.it.
Non sappiamo ancora se si sia trattato di una scelta deliberata dell'attaccante o semplicemente del risultato della fonte utilizzata per costruire la lista dei destinatari. Ma il risultato è piuttosto eloquente.
In pratica, l'attacco non ha colpito il sistema scolastico italiano nella sua interezza. Ha colpito una particolare popolazione di indirizzi e-mail, riconducibile all'infrastruttura del Ministero.
E questo ci dice qualcosa anche sul modo in cui è stata preparata la campagna: evidentemente chi l'ha organizzata disponeva di una lista di destinatari sufficientemente ampia da raggiungere migliaia di istituti, ma non necessariamente di una mappatura completa delle scuole italiane.
Il Trentino, l'Alto Adige e la Valle d'Aosta sono rimasti fuori perché utilizzavano un'infrastruttura di posta differente.
E, paradossalmente, questa separazione amministrativa e tecnologica ha funzionato come una forma di isolamento. Ora, però, proviamo a ragionare sulla cosa.
Se qualcuno ha raccolto 6.300 indirizzi di dirigenti scolastici, tipicamente avrà utilizzato uno scraper, uno scanner o qualche altra forma di raccolta automatizzata delle informazioni pubblicamente disponibili. E, se ha fatto un lavoro del genere, è piuttosto probabile che abbia raccolto anche gli indirizzi delle scuole altoatesine e trentine.
Di conseguenza, c'è un'altra possibile spiegazione per la loro mancata ricezione delle e-mail: non è detto che l'attaccante le abbia escluse. Potrebbero essere state semplicemente intercettate dai sistemi di protezione della posta in ingresso. Niente di nuovo e niente di strano.
In altre parole, mentre migliaia di scuole italiane ricevevano regolarmente il messaggio, i sistemi delle province autonome potrebbero averlo riconosciuto e bloccato prima ancora che arrivasse nelle caselle dei destinatari.
È un'ipotesi, naturalmente. Per dimostrarla servirebbero i log dei rispettivi sistemi di posta. Ma, IMHO, è una spiegazione tecnicamente plausibile: la differenza potrebbe non essere stata nella lista degli indirizzi raccolti dall'attaccante, ma nelle protezioni installate da chi riceveva quei messaggi.
E se fosse così, avremmo un confronto piuttosto interessante fra infrastrutture pubbliche che gestiscono lo stesso tipo di minaccia con risultati molto diversi.
Non ci vuole molto ad investigare le differenze:
E qui arriviamo alla parte interessante
A questo punto ho voluto verificare direttamente come fosse configurata l'infrastruttura di posta elettronica della Provincia autonoma di Bolzano. Non c'è bisogno di avere accesso ai sistemi interni: basta interrogare il DNS.
Il risultato è piuttosto interessante:
$ host provincia.bz.it
provincia.bz.it has address 150.171.109.107
provincia.bz.it mail is handled by 0 mx08-0067de01.pphosted.com.
provincia.bz.it mail is handled by 0 mx07-0067de01.pphosted.com.
I record MX, cioè quelli che indicano quali server ricevono la posta destinata a un dominio, puntano a due host appartenenti all'infrastruttura pphosted.com.
Non è un dettaglio qualsiasi: si tratta dell'infrastruttura hosted di Proofpoint, uno dei principali operatori nel settore della sicurezza della posta elettronica.
Per curiosità, ho anche verificato direttamente la raggiungibilità del primo gateway SMTP:
$ telnet mx08-0067de01.pphosted.com 25
Trying 143.55.150.164...
Connected to mx08-0067de01.pphosted.com.
220 mx08-0067de01.pphosted.com ESMTP mfa-m0446002
Insomma, non stiamo parlando semplicemente di un server di posta qualsiasi. La Provincia autonoma di Bolzano espone verso Internet un gateway SMTP appartenente all'infrastruttura Proofpoint.
E qui il quadro diventa interessante.
Proofpoint commercializza sistemi di protezione della posta elettronica che comprendono filtraggio antispam, rilevamento del phishing, analisi dei messaggi e protezione contro campagne malevole. Sono esattamente gli strumenti che servono a impedire che una comunicazione sospetta raggiunga migliaia di caselle di posta.
Naturalmente, non posso affermare che sia stato proprio Proofpoint a bloccare le email della campagna in questione: per dimostrarlo servirebbero i log del gateway o una conferma dell'amministrazione provinciale.
Ma abbiamo un dato tecnico verificabile: l'infrastruttura di posta altoatesina utilizza un gateway di sicurezza Proofpoint, mentre le scuole appartenenti al sistema ministeriale nazionale sono state raggiunte dalla campagna di minacce.
La differenza merita quantomeno un'indagine.
Perché, se davvero il gateway altoatesino ha intercettato quei messaggi, potremmo trovarci davanti a un esempio molto concreto di quello che intendo quando parlo di sciatteria tecnica: non è necessario inventare nuove tecnologie, né costruire chissà quali sistemi di difesa. A volte basta comprare, configurare e mantenere correttamente gli strumenti che il mercato offre già da anni.
C'è anche un altro aspetto da considerare. Questa è, in un certo senso, una forma di security by design.
La scelta dell'infrastruttura non è neutrale. Se decido di affidare la gestione della posta elettronica a un provider specializzato che offre, come parte integrante del servizio, un'infrastruttura di protezione contro spam, phishing e altre minacce, sto incorporando una parte della sicurezza nella scelta stessa del servizio.
Non devo necessariamente costruire tutto in casa, assumere un'intera squadra di specialisti o inventarmi un sistema proprietario. Posso acquistare un servizio che nasce già con determinate caratteristiche di sicurezza.
Naturalmente, questo non significa che basti mettere Proofpoint davanti a un server SMTP per essere invulnerabili. I sistemi vanno configurati, aggiornati e monitorati. Ma significa che una parte importante della protezione viene delegata a un'infrastruttura specializzata, che ha proprio questo mestiere.
E soprattutto significa che la sicurezza non viene considerata un'aggiunta da comprare eventualmente in seguito, quando succede qualcosa. È una caratteristica della scelta architetturale iniziale.
E il Ministero? Non è che fosse completamente sprovvisto di protezioni.
A questo punto ho voluto fare la stessa verifica anche per il dominio del Ministero dell'Istruzione.
$ host istruzione.it
istruzione.it has address 23.36.163.237
istruzione.it has address 23.36.163.251
istruzione.it mail is handled by 10 istruzione-it.mail.protection.outlook.com.
Il record MX è piuttosto esplicito: la posta destinata a istruzione.it viene instradata verso un gateway Microsoft Exchange Online Protection (EOP).
Ho verificato anche la raggiungibilità del servizio SMTP:
$ telnet istruzione-it.mail.protection.outlook.com 25
Trying 52.101.91.21...
Connected to istruzione-it.mail.protection.outlook.com.
220 MAD0EPF000008C4.mail.protection.outlook.com
Microsoft ESMTP MAIL Service ready at Thu, 12 Nov 2026 18:11:27 +0000
Insomma, anche il Ministero utilizza un'infrastruttura di posta Microsoft che dispone nativamente di funzionalità antispam e antiphishing.
E questo è un particolare importante, perché impedisce di liquidare la questione dicendo semplicemente che il Ministero non aveva comprato un sistema di protezione.
Un gateway Microsoft Exchange Online Protection non è un semplice server SMTP: dispone di meccanismi di filtraggio della posta indesiderata, rilevamento del phishing e protezione dalle minacce.
Tuttavia, Microsoft offre diversi livelli di protezione. Exchange Online Protection costituisce il livello di base, mentre Defender for Office 365, nelle sue diverse versioni, aggiunge ulteriori funzionalità di analisi e difesa.
Non sappiamo quali licenze fossero state acquistate dal Ministero, quali funzionalità fossero abilitate e, soprattutto, come fossero state configurate le policy di sicurezza del tenant.
Ed è qui che il confronto con la Provincia autonoma di Bolzano diventa interessante.
Da una parte abbiamo un'infrastruttura che utilizza Proofpoint come gateway SMTP; dall'altra un'infrastruttura che utilizza Microsoft Exchange Online Protection.
Entrambe dispongono, almeno a livello di architettura, di strumenti professionali per la protezione della posta elettronica.
Non abbiamo ancora la prova che Proofpoint abbia bloccato la campagna né che Microsoft l'abbia lasciata passare per un errore di configurazione. Per arrivare a una conclusione del genere servirebbero i log dei rispettivi gateway.
Ma abbiamo individuato una domanda molto più precisa di quella iniziale:
quali livelli di protezione erano stati effettivamente acquistati, configurati e attivati dal Ministero dell'Istruzione?
Perché acquistare un servizio di sicurezza e utilizzarlo al livello minimo non sono necessariamente la stessa cosa. E avere una tecnologia disponibile non significa automaticamente averla configurata per sfruttarne tutte le capacità.
È proprio questa la differenza fra comprare un prodotto e progettare un'infrastruttura sicura.
Quando poi la mail è arrivata, abbiamo già detto qual è stato il risultato. Nessun dirigente scolastico sembrava avere un processo operativo comune da seguire. Nessuno sapeva esattamente cosa fare. Ognuno ha improvvisato, con risultati diversi e, in alcuni casi, francamente grotteschi.
Ancora: sciatteria, sciatteria e sciatteria.
E qui arriviamo al punto.
La Pubblica Amministrazione italiana, ma anche quella di altri paesi, ha sempre avuto un problema con l'IT. È un settore pervasivo: tende a essere presente ovunque, attraversa praticamente ogni attività amministrativa e, proprio per questo, viene spesso trattato come una specie di servizio accessorio.
Ma l'informatica ha due caratteristiche che la rendono particolarmente difficile da gestire con i normali meccanismi della burocrazia.
La prima è che si tratta di un settore dominato dalla competenza tecnica specifica. Non basta avere una qualifica generica, un'anzianità di servizio o aver superato un concorso. Occorre conoscere le tecnologie, le architetture, i protocolli, i sistemi e le loro implicazioni. In un mondo organizzato intorno a concorsi, anzianità e relazioni personali, ci troviamo davanti a un settore nel quale il conflitto fra le best practice tecniche e altre esigenze, generalmente definite «politiche», tende troppo spesso a risolversi a favore di queste ultime.
La seconda caratteristica è ancora più importante quando scendiamo nel campo della sicurezza dei sistemi e degli asset in generale, dati compresi. È un mondo nel quale una decisione incompetente può provocare un disastro. Non necessariamente domani mattina, e nemmeno necessariamente in modo immediatamente visibile. Ma le conseguenze possono essere enormi, perché un errore architetturale, una configurazione sbagliata o una procedura inesistente possono compromettere interi sistemi.
In definitiva, attraverso il rifiuto sistematico della competenza — che non è la stessa cosa del merito — e della sua importanza, il mondo della Pubblica Amministrazione ha costruito una particolare dialettica organizzativa.
La competenza tecnica viene considerata una competenza di chi lavora. È qualcosa che serve a chi materialmente mette le mani sui sistemi, scrive il codice, configura i server o gestisce le reti.
Poi, sopra, c'è la «politica». E, quando necessario, c'è la «burocrazia».
Il tecnico può anche sapere perfettamente cosa sarebbe necessario fare. Ma la decisione spetta ad altri, che non necessariamente possiedono le conoscenze per valutarne le conseguenze. E che, soprattutto, non sono sempre interessati a farlo.
Risultato?
Il prodotto più comune della PA è la sciatteria.
Una sciatteria molto ben giustificata, naturalmente.
«È stato un errore del computer» è una spiegazione che sembra funzionare benissimo, anche quando l'errore è stato commesso dal tizio che ha materialmente battuto i tasti. Il computer, in questo schema, diventa una specie di entità soprannaturale, responsabile di tutto ciò che gli esseri umani non vogliono assumersi la responsabilità di aver fatto.
Anche la visione degli hacker come ragazzi tatuati, coperti di piercing e capaci di guadagnare milioni è assolutamente comune. E quindi, naturalmente, troppo costosi da assumere. Si dimentica che la sicurezza informatica non è una specie di magia nera praticata da personaggi usciti da un film di Hollywood, ma un settore professionale con competenze, procedure e specializzazioni precise.
E si dimentica soprattutto un'altra cosa: nella Pubblica Amministrazione ci sono spesso tecnici competenti, persone che vorrebbero semplicemente fare il proprio lavoro e applicare le conoscenze che hanno acquisito. Ma che vengono zittite, umiliate e tenute fuori dal circolo delle decisioni.
Non per nulla, se lavorate nell'IT, quando sentite parlare di «una decisione politica», spesso sapete già cosa significa nella pratica: una decisione che i tecnici considerano semplicemente incompetente. Il vostro capo vi sta dicendo "so che e' una cazzata, ma questo e' stato deciso e noi peones non possiamo farci nulla".
E il problema non è che la politica decida. È perfettamente legittimo che lo faccia.
Il problema è quando la decisione politica pretende di sostituirsi alla competenza tecnica, anziché utilizzarla per decidere consapevolmente. Perché a quel punto non stiamo più parlando di una scelta fra diverse strategie possibili. Stiamo parlando di qualcuno che decide senza sapere quali conseguenze produrrà la propria decisione.
E quelle conseguenze, prima o poi, qualcuno le paga.
Il guaio è che stiamo entrando nel periodo storico nel quale la sciatteria e l'incompetenza hanno un prezzo.
E adesso sono nel panico, e cercano di fare quello che hanno sempre fatto: convincere le persone che gli hacker siano una specie di stregoni invincibili, capaci di entrare ovunque e di superare qualsiasi difesa.
Corpi speciali di Stati stranieri, organizzazioni misteriose dotate di capacità tecnologiche quasi soprannaturali. Una narrazione che, incidentalmente, assolve l'incompetenza di chi ha lasciato l'intero Ministero dell'Istruzione senza un sistema di protezione degli endpoint adeguato e non ha mai addestrato i dipendenti su cosa fare quando ricevono una mail di spam o di phishing.
Saranno portati a farvi credere che gli hacker utilizzino tecniche sofisticatissime, contro le quali è impossibile difendersi. Che siano talmente bravi da rendere inutile qualsiasi precauzione.
Perché, se qualcuno cominciasse a dire che lo spam esiste da decenni, che il phishing è una tecnica vecchia quanto Internet e che, forse, il problema è la sciatteria tecnica della Pubblica Amministrazione e dei suoi dirigenti, magari qualcuno finirebbe per porsi qualche domanda.
Ma è ora di dirlo chiaramente: per impedire che succedesse quanto è successo sarebbe bastato un architetto di sistemi DECENTE, insieme a un dirigente cui venisse in mente di spiegare ai presidi come reagire a una minaccia di quel tipo e di organizzare la relativa formazione.
Non sto facendo una questione di merito puro. Non sto dicendo che i tecnici debbano diventare i nuovi dirigenti, né che ogni decisione debba essere sottratta alla responsabilità amministrativa e politica.
Sto parlando di competenza.
Sto dicendo che i dirigenti dovrebbero capirci qualcosa. Oppure, almeno, dovrebbero essere capaci di fidarsi dei propri tecnici quando questi spiegano loro quali sono i rischi e come si possono affrontare.
Ma, a quanto pare, si preferisce la sciatteria.
Sapete cos'è successo, probabilmente? È una dinamica che ho già visto succedere parecchie volte.
Un dirigente ben ammanicato deve ricevere posta elettronica da un fornitore cantinaro, che gestisce un server SMTP da due lire. La posta non gli arriva perché il sistema di protezione la blocca. Allora chiama e chiede che l'endpoint protection venga disattivata, perché lui «ha bisogno della posta per lavorare».
Fine.
È una dinamica semplicissima. Con questo genere di «processo» ho visto aprire server FTP e SFTP, ho visto aprire firewall, concedere accessi VPN e autorizzare ogni genere di sciatteria tecnica. Tutto sulla base dello stesso principio: le ragioni dei tecnici vengono ignorate alla prima escalation di qualcuno che conta più di loro nell'organigramma.
Se volete sapere di chi è la colpa di questo disastro, probabilmente non dovete fare altro che andare a Roma e chiedere chi sia quel coglione che ha fatto spegnere l'endpoint protection perché non riusciva a ricevere la posta da qualche cantinaro incapace con un server da due lire.
Perché sì, novanta volte su cento succede così.
Non sto dicendo che sia necessariamente successo proprio questo al Ministero. Non abbiamo i log delle modifiche alle policy di sicurezza e non conosciamo le decisioni prese dai responsabili dell'infrastruttura. Sto descrivendo un meccanismo che ho visto ripetersi molte volte e che, nel settore, è tutt'altro che sconosciuto.
Sciatteria.
Semplice, banale sciatteria.
Solo che le regole del gioco sono cambiate. E adesso la sciatteria ha un prezzo, perché c'è una guerra ibrida in corso.
Ed è proprio per questo che continuo a proporre, come soluzione, la segregazione delle reti. Perché, in fondo, c'è un principio che dovremmo finalmente accettare.
Certa gente, su Internet, non dovrebbe proprio starci.
Semplicemente.
Uriel Fanelli
- Written using Wortwerk
- Fedi: @uriel@x.keinpfusch.net
- XMPP:
uriel@keinpfusch.net - Matrix: @uriel:chat.keinpfusch.net
- Email: blog@keinpfusch.net