Non sono un esperto di geopolitica, come non sono un esperto di pandemie e quindi mediamente mi asterrò dal fare commenti (pur avendo idee precise in merito) su quello che stà avvenendo in Ucraina cosi come non commento le vicende pandemiche.
Ma so che la guerra fa schifo, fa male e può anche ammazzarti, e so che farà soffrire persone che conosco e a cui voglio bene.
Non posso che sperare per il meglio.
I am not an expert in geopolitics, just as I am not on pandemics. Therefore, I will refrain from making comments (despite having precise ideas about it) on what is happening in Ukraine as I do not comment on the pandemic events.
But I know that war sucks, hurts, and can even kill you, and I know it will hurt people I know and love.
Mentre leggiamo gli sviluppi futuri della appena nata Agenzia per la Cybersicurezza Nazionale, noi che lavoriamo in questo settore da anni siamo presi da due fuochi contrapposti:
da un lato la speranza che finalmente in Italia cambi qualcosa in merito all’approccio sulle questioni inerenti la sicurezza informatica
dall’altro il timore che si replicheranno meccanismi ormai consolidati e verticistici che hanno portato spesso ad una adesione formale ma non sostanziale alle esigenze del paese in merito a tale sicurezza.
Intendiamoci, le colpe non sono interamente da afferire ai governi e le amministrazioni passate. Deficienze culturali e scarsa competenza sui temi della digitalizzazione sono piaghe non solo della PA ma di tutto il comparto produttivo italiano, che soffre, fatte le dovute eccezioni, di una arretratezza digitale strutturale.
Se davvero vogliamo avere successo in un percorso in cui la digitalizzazione diventi davvero digitalizzazione e non mera aggiunta di componenti digitali, spesso mal progettati, su processi analogici, se davvero vogliamo davvero introdurre l’accountability (che non vuol dire attribuzione delle colpe, ma “responsabilità” nel senso più alto: decisionale e di indirizzo), se realmente vogliamo che la sicurezza dell’informazione diventi una componente chiave nello sviluppo nel nostro substrato industriale e della pubblica amministrazione occorre mettere i piedi per terra ed affrontare la realtà.
La disproporzione tra il “percepito” e la “realtà” in cui l’Italia si trova in termini di coscienza e conoscenza digitale è molto elevata. E questo è legato a diversi aspetti prima citati, ma anche ad un approccio che è sempre stato legato ad una adesione “formale” e non “sostanziale” alle esigenze del paese.
Non si tratta delle solite lamentele di un gruppo di “nerd” slegati dalla realtà. Si tratta di problematiche concrete, che hanno anche colpito le capacità del sistema paese di competere da pari in un mondo ove l’informatica è oramai una conditio sine qua non.
Una incapacità di vedere che ci ha portati ad essere il terzo paese in termini di attacchi ransomware, mentre la consapevolezza digitale è ai livelli più bassi d’europa.
Gli stipendi e le possibilità di carriera sono solo uno degli aspetti per cui molti hanno dovuto o voluto trasferirsi all’estero.
La mancanza della percezione del “valore” della sicurezza informatica e della competenza ed esperienza richiesti è uno degli elementi, ma la mancanza di un mercato che punti sulla qualità ed il riconoscimento della importanza di tali competenze è un’altro fattore non trascurabile.
E su questi non si lavora solo in termini di “stipendio”. Già in passato si fecero tentativi, in altri settori, di far rientrare i cervelli con scarsi risultati. Questi rientrano solo se oltre al lancio momentaneo di programmi di corto respiro che possano fingere da “specchietto delle allodole” esiste una concreta volontà di creare un ambiente adatto alla loro permanenza.
Un ambiente che favorirebbe anche la crecita interna delle competenze che servono.
Mentre aspettiamo che arrivi il 2023 con il personale assunto dalla Agenzia, perchè questa sia di utilità reale e fattiva, e che possa incidere in maniera positiva sulle esigenze oramai non rimandabili del sistema paese occorre realizzare che non sono 300 esperti che rientrano o vengono assunti che potranno cambiare le cose.
Il paese, e la sicurezza informatica, non ha bisogno solo di Penetration Tester o Ethical Hackers, che pur essendo elementi importanti nel discorso della sicurezza informatica non ne coprono completamente tutti gli aspetti. Abbiamo bisogno di manager competenti, di strutture apicali che comprendano e sappiano valutare i rischi informatici con una prospettiva che tenga conto delle loro esigenze di business e delle necessità del paese.
Ma occorre anche capire che la creazione di queste risorse richiede tempi e attività che non possono venire da un approccio apicale che dia, in maniera astratta, indicazioni che poi non possono essere calate nella realtà.
Occorre immergersi nella realtà del paese e capirne quale sia il concreto livello di comprensione, maturità, competenza e necessità.
Non ho dubbi che, data la provenienza del dott. Baldoni, esistano già forti legami, ad esempio, col mondo universitario, ma questo non basta.
In questo senso il coinvolgimento delle associazioni di categoria in un virtuoso rapporto di scambio di informazioni che, da un lato, delinei le esigenze e dall’altro le difficoltà, sarebbe da auspicarsi come tavolo permanente di confronto.
E, altresì, sarebbe necessario aprire tavoli diretti con i vendor che fanno digitalizzazione e sicurezza al duplice scopo di avere un quadro chiaro di quali siano le esigenze da parte del paese in termini di sicurezza da trasmettere ai vendor, e quale sia il percepito dei vendor in merito a tali esigenze contestualizzati alle tecnologie correnti, trend di sviluppo, e, perchè no, anche suggerimenti ed esperienze.
Infine ci sono coloro che da anni lavorano alla sicurezza informatica anche qui in Italia, e che hanno maturato una esperienza ed una visione chiara di quali siano i limiti e le esigenze da indirizzare nel paese che potrebbero fornire ai 300 giovani e forti, all’agenzia ed al paese intero un supporto di comptenze ed esperienze che fin troppo è stato, se non trascurato, non valutato pienamente. Penso a persone che lavorano nei molteplici aspetti della sicurezza e che hanno competenze sui vari domini, ivi compresa compliance o aspetti di informatica legale.
In questo senso mi viene facile nominare #clusit, #aipsi, #aipsa ma anche altre associazioni che sul territorio da anni cercano di portare consapevolezza e conoscenza, penso ancora a ruota libera a eventi di valore assoluto come #HackIngBo.
Spett. Agenzia, se vogliamo che il vostro sia un esercizio non teorico ma un concreto supporto al paese occorre allora aprirsi sin da subito al paese stesso, e se è vero che vi sono risorse preziose che sono all’estero, è anche vero che non ascoltare i territori e le loro esigenze è un approccio che non può portare altro che alla compliance di carta e non alla reale e feconda collaborazione che sola può indirizzare le problematiche culturali e di conoscenza che in questo momento pongono il nostro paese in una non soddisfacente posizione in termini di sicurezza informatica.
Forse 300 persone, tra cui neolaureati, potranno mettere in moto il motore della agenzia, ma questa non inciderà nel paese se nel paese non porrà radici, ascolto e comprensione.
cordialmente
Antonio Ieranò
PS: grazie per chi ha avuto la voglia, la pazienza ed il tempo di leggere. In questo caso i commenti sono ben voluti, che è ora di rimboccarsi le maniche e mettere in moto il cambiamento.
Dopo aver parlato per un po di posta elettronica discorrendo di “safe” e “block” list incomincio a rendermi conto che forse un passo indietro si rende necessario, e quindi mi pongo la domanda: ma tu sai come funziona la posta?
La risposta varia generalmente in funzione di chi riceve la domanda e, nella maggior parte dei casi, è sbagliata.
Questo basso livello di comprensione di come funziona la posta elettronica è in realtà una delle ragioni del suo successo. Mandare email è facile per un utente qualsiasi, persino per un manager IT, non c’è molto apparentemente da capire.
Purtroppo, non capire come funziona un sistema apre la porta anche ad errori gestionali, incomprensioni, aspettative errate, mostruosità da DPO e amenità associate.
Ora per capire un minimo come funziona la posta ho deciso di partire dal livello di comprensione di un utente medio, per poi passare dalla visione di un IT manager per finire al è punto di vista della posta medesima.
Introduciamo quindi i primi soggetti che ci introdurranno nel dorato mondo della posta elettronica.
Siccome vorrei che la lettura di questo articolo fosse accessibile ai più, proprio per venire incontro alle nuove esigenze linguistiche, analogamente all’uso di safe e bloc list ho deciso di rendere aperto il mondo dei nostri test non definendo nessun orientamento di sorta.
Per cui i nostri generici soggetti saranno Ann* e Ug*
Siccome confesso di avere problemi di dizione quando occorre citare i soggetti, eviterò di nominarli se non in qualche riferimento obbligatorio che mi rifiuterò di leggere ad alta voce. (ROTFL)
La posta secondo gli utenti
Immaginiamo ora che i nostri due tester (il vantaggio di uso di un termine inglese qui è puramente linguistico) siano usi mandarsi reciprocamente dei messaggi di posta elettronica.
Entrambi i soggetti usano probabilmente un programma per la posta elettronica (ad esempio Microsoft outlook) o una interfaccia web (Gmail, Microsoft OWA, Libero scegliete voi). Probabilmente non sono in grado di distinguere il fatto che è una app, un software o una interfaccia web sempre di client parliamo, ma si sa, queste sono cose da tecnici.
Di quale sia il contorno ed il contesto della posta ai nostri due utenti importa molto poco.
A loro è stato insegnato che per mandare un messaggio di posta occorrono 3 cose:
dire a chi si manda la posta con un indirizzo del tipo nome@unarobadopo.xx
mettere un oggetto, insomma il titolo della email.
scrivere qualsiasi cosa, aggiungere testo immagini, file, cotechini e via dicendo
Tutto il resto è assimilabile alla magia ed alle categorie della magia si associano le percezioni ed aspettative relative, in particolare:
la posta è istantanea, come mando arriva
se leggo che il messaggio arriva da “pippo” deve essere “pippo” che la ha mandata
se c’è un allegato prima clicco e poi penso, che se “pippo” me lo manda un motivo ci sarà
se c’è un link ci clicco, del resto anche il web è magico (e le pagine sono pagine vere)
Questa percezione è estremamente radicata, del resto chi di noi conosce in dettaglio come funzionano gli SMS (ok non si usano più) o uazzap?
In compenso l’uso è così semplice che con la posta si mandano messaggi, appuntamenti, si gestiscono contenuti sensibili, si archiviano informazioni sensibili, personali, coperti da Proprietà Intellettuale e via dicendo.
Insomma, nella nostra posta viene raccolta la maggior parte delle informazioni che coprono la nostra vita lavorativa ed in parte privata e la gestiamo con la consapevolezza di chi utilizza uno strumento magico.
La posta secondo gli IT manager
Per fortuna gli IT manager hanno una visione della posta ben più complessa ed articolata. Introducono nella equazione il concetto di Mail Server.
Ora cosa sia un mail server non è comunque chiarissimo, è un oggetto che colleziona le caselle di posta degli utenti e che manda e riceve posta su internet.
I più tecnicamente savi hanno anche la percezione che tra il client di posta, outlook ad esempio, e il mail server (ad esempio Exchange) esista una comunicazione gestita da un protocollo con un nome esoterico, tipo MAPI nel caso di server di posta Microsoft. Non cito Office365 volutamente per non creare angosce emotive (dover citare Exchange online come componente va al di là della percezione di molti)
Intendiamoci, prima che si levi l’ondata di indignazione per aver osato citare un prodotto Microsoft esistono diversi protocolli che possono gestire la transazione client server, se nel mondo Microsoft MAPI va alla grande (fa tutto lui, anche la configurazione del client) in altri casi si devono usare cose più complesse tipo SMTP per l’outbound e IMAP o POP per l’inbound (se volete posso anche parlare di queste cose in un post futuro, chiedete e vi sarà dato).
Una delle maggiori differenze tra un utente standard ed un IT manager è la percezione, da parte di un IT manager, che il fatto che un messaggio sembri arrivare da un certo mittente perché presente nel campo “FROM: ” non è una garanzia.
Egli, ella, el* è consapevole che vi siano anche casi in cui può arrivare posta “pericolosa”. Una volta si chiamava SPAM, oggi si è scoperto che la posta è anche vettore di ben altri pericoli di cui, se volete, parleremo in seguito.
Dal punto di vista del funzionamento del sistema spesso la comprensione del mondo legato alla posta elettronica solitamente si ferma al mail server.
Già questo potrebbe dare adito a concetti interessanti in ottica gestionale, ad esempio:
quanto importanti sono i servizi di posta elettronica all’interno dei miei processi di business?
uso la mail con i miei clienti?
uso la mail con i miei fornitori?
uso la mail per fini marketing?
…
quale è la mia esposizione al rischio su questo canale?
quanti dati business critical sono contenuti nello store del mio mail server?
quanta proprietà individuale è contenuta nel datastore del mail server?
quante informazioni “critiche” per il business?
…
come differenzio la gestione dei dati personali rispetto quelli aziendali contenuti nel mio mailserver?
Che impatti ci sono sul GDPR collegati alla gestione delle caselle di posta elettronica?
Ovviamente sono sicuro che queste ed altre osservazioni sono comuni in fase di disegno e manutenzione dei sistemi postali da parte del management.
Il problema è che dopo il mail server la percezione di cosa sia la posta elettronica ritorna a quella magica dell”utente finale.
La percezione di “istantaneità” ad esempio è comune, la idea di “non posso bloccare in nessun modo la posta” anche. Ma avendo una scarsa comprensione dei meccanismi che governano la posta difficilmente sono in grado di fare analisi coerenti.
La posta secondo la posta
Se dovessimo chiedere ai sistemi di posta elettronica cosa sia la posta elettronica probabilmente avremmo una descrizione un poco più complessa.
La visione che la posta ha di sé stessa sicuramente è più complessa.
Questa “complessità” copre quasi tutte le cose viste prima, da come sia formattata una e-mail a come sia gestita la distribuzione dei messaggi di posta.
Purtroppo, questa comprensione è fondamentale per poter gestire e securizzare correttamente i sistemi, quindi occorrerebbe capire almeno le basi.
La prima cosa che balza all’occhio è che il mondo della posta non si ferma al server di posta elettronica. tutti i sistemi di posta elettronica, infatti, hanno bisogno di una componente che formatti i messaggi in una modalità trasmissibile su internet.
Il protocollo utilizzato per trasportare la posta si chiama SMTP (Simple Mail Transfer Protocol) ed ha caratteristiche specifiche che vanno considerate su cui farò considerazione dopo.
La prima cosa importante da capire è che la gestione delle caselle di posta è cosa diversa dalle problematiche di invio e ricezione dal server stesso.
La trasmissione della posta verso l’esterno è, invece, gestita da connettori che utilizzano il protocollo SMTP.
Quando scriviamo una mail sul nostro client questo la formatta e invia al mail server, che si incarica della sua gestione (storage, distribuzione interna, distribuzione esterna). Se il messaggio deve essere mandato al di fuori del server di posta, questo incarica la componente di gateway SMTP per trasferire il messaggio verso la destinazione prevista.
I nodi SMTP possono essere molteplici e seguono una catena che arriva fino alla destinazione finale: il connettore SMTP del mail server che contiene la casella dell’utente cui è stato inviato il messaggio.
Per garantire questa transazione occorrono diversi elementi: la presenza sui DNS di elementi che consentano la “traduzione” del dominio di posta in un server (tipicamente gli MX record) protocolli accessori che permettano la identificazione dei mittenti (SPF o DMARK) o la firma di contenuti (DKIM), fino a sistemi di encryption (SMIME) ed altro.
La trasmissione di un’email è quindi una questione relativamente complessa. Relativamente significa che molti di questi elementi sono però “opzionali” ed alla fine il protocollo SMTP permette l’invio di un messaggio semplicemente inviando i comandi manualmente senza effettuare controllo alcuno di veridicità.
Come è fatto un messaggio di posta.
Iniziamo a capire come sia realmente fatto un messaggio di posta. L’email di posta che riceviamo ed apriamo in outlook è molto più complesso di quello che sembra.
Ma capire cosa sia realmente ci permette di capire quali possano essere le problematiche di gestione e sicurezza di un sistema di posta sia lato utente, che lato IT manager ed infine (ma si spera lo sappiano già) di coloro che si occupano di sicurezza informatica.
PS: L’e-mail nella immagine è indirizzata a me e ne autorizzo la visione, non sto violando quindi i miei diritti e la mia confidencialita.
Quello che dobbiamo capire è che tra quello che vediamo e quello che c’è in background ci sono delle differenze sensibili.
Quando apriamo un messaggio su outlook, webmail o client di vostra preferenza quello che vediamo è una rappresentazione delle informazioni contenute nel reale messaggio.
le prime cose che solitamente si notano sono:
chi manda il messaggio, rappresentato dal campo FROM: (Da:)
a chi è inviato il messaggio rappresentato dal campo TO: (A:)
l’oggetto del messaggio, solitamente del testo che dà indicazioni dei contenuti, ma oggi in grado anche di mostrare elementi grafici.
Il corpo del messaggio, che contiene immagini, link, colori.
Eventuali attachment (allegati) che espandono i contenuti dei messaggi di posta elettronica in formati di qualsiasi tipo.
La vera struttura del messaggio la possiamo vedere nella immagine seguente.
Se vediamo nel dettaglio cosa contenga questa roba complessa possiamo sentirci intimiditi, per la vostra tranquillità quindi evidenzierò le componenti che servono.
iniziamo da chi manda la email.
Nell’esempio di outlook vediamo un mittente, ma se guardiamo nella struttura reale della email vediamo che il mittente è
Come si vede è abbastanza diverso da quello che si vede nel messaggio aperto su outlook.
cosa significa questo?
Significa, semplicemente, che quello che si vede nelle intestazioni tecniche della e-mail non corrisponde a quello visibile.
In effetti le email hanno due intestazioni una tecnica in uso al protocollo SMTP ed una visibile rappresentata dal client di posta.
La relazione tra le due intestazioni è nulla, nel senso che le due sono indipendenti e non esiste nessun vincolo di relazione tra i campi equivalenti delle due intestazioni.
La intestazione tecnica, quindi, non è visibile a livello di client di posta, ma a che serve?
Gli header tecnici sono il frutto della conversazione che hanno i gateway SMTP di posta. Ne riporto in basso una versione semplificata.
I limiti ed i pregi dell’SMTP
Come scrivevo sopra la trasmissione tra i nodi di posta viene gestita dal protocollo SMTP che, prima di ogni invio, deve gestire un Handshake.
Lo scopo di questa transazione è quello di preparare la comunicazione tra mittente e destinatario e di fornire un responso in merito alla transazione stessa.
Tutte le informazioni trasferite sono in chiaro, il protocollo non esegue nessuna forma di encryption o offuscamento, né di controllo di veridicità delle informazioni trasmesse se non in maniera estremamente limitata.
La mancanza di controllo da parte del protocollo sulla veridicità dei dati trasmessi implica che tali controlli, opzionali, siano interamente in carico al nodo di destinazione.
La mancanza di verifica o certificazione del mittente consente la trasmissione di traffico da parte di qualunque sorgente, le specifiche di protocollo, infatti, non vincolano nessuna caratteristica specifica in carico al mittente.
Ogni voce dello scambio genera da parte del server di destinazione, un codice che identifica la corretta trasmissione della componente di informazione che serve a costruire la mail, o l’eventuale errore.
Una osservazione che dovrebbe destare l’interesse di chi vuole capire come funziona il meccanismo è che una mail viene considerata consegnata da parte del mittente solo se a sequito del QUIT ottiene un 250 come codice di risposta. Questo significa che una mail viene considerata “consegnata” dal mittente solo ed esclusivamente quanto l’intero flusso del messaggio viene accettato dal destinatario.
Tutto chiaro, peccato che…
il mail from della sessione SMTP non è quello che legge l’utente
il dominio dichiarato in HELO\EHLO può non corrispondere al dominio visibile nel mail from dell’utente
il protocollo non esegue nessun controllo di veridicità sui dati trasmessi dal mittente, questi sono eventualmente in carico a servizi opzionali del destinatario
il protocollo non esegue nessun controllo sulla identità del mittente
i comandi trasmessi in una sessione SMTP sono in chiaro
la transazione SMTP può contenere campi ulteriori tra cui «reply to:» e cose del genere
dopo DATA si può mandare di tutto e di più, ivi compresi mittente e destinatario visibili nel client di posta
l’integrazione di Mime nel campo DATA consente di mandare formati non testuali, ecco come ci arrivano l’e-mail in HTML
l’HTML ci consente grafica, caratteri diversi, componenti di codice attivo non visibile…
Ok non ho spiegato tutto, ma lo scopo non è darvi il dettaglio ma fornire una base per poter postare in futuro osservazioni, indicazioni, suggerimenti analoghi a quelli fatti per “safe” o “block” list con un minimo di confidenza che se manca abbiate un riferimento per comprendere il quadro tecnico di cui si parla.
Tra gli argomenti che vorrei toccare prossimamente negli E-mail files ci sono:
E-mail design for dummies: le 4 o 5 cose che devi assolutamente sapere
I protocolli di autenticazione, da SPF a DMARC
Cosa serve e come funziona un security gateway,
Il caso per l’encryption: come, dove, cosa e perché
Perché se temete che i servizi di reputation blocchino le e-mail non avete capito nulla di come funziona il protocollo SMTP né dei vincoli di legge sulla accettazione obbligatoria di messaggi di posta elettronica
Perché se non capite la differenza tra E-mail gateway e server di posta non siete in gradi di fare nessuna considerazione in merito al GDPR (ma solo perché non potete fare valutazioni di rischio se non avete idea di cosa state valutando)
Implementare sistemi di #security che non comunichino tra loro significa implementare silos che disperdono #dati e non consentono di inquadrare l’esposizione al #rischio.
14.50 Threat Intelligence: la sicurezza come sistema integrato Oggi implementare sistemi di sicurezza che non comunichino tra loro significa implementare silos che disperdono informazioni preziose e non consentono di inquadrare l’esposizione al rischio nel suo complesso. Proofpoint propone un approccio olistico e integrato in cui la risorsa da proteggere è l’utente, e capirne l’esposizione al rischio è fondamentale. Antonio Ieranò, Evangelist-Cyber Security Strategy – Proofpoint Italy
