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
Nel post precedente ho iniziato a dissertare della gestione della posta elettronica soffermandosi sul problema annoso delle safelist (allowlist, whitelist o come preferite chiamarle).
Non sarebbe una trattazione esaustiva se non affrontassi il duale delle safelist, le blocklist.
Se ricordiamo la genesi della safelist questa è legata ai uno dei due problemi legati ai filtri di sicurezza che qui riporto per completezza:
1) il filtro non blocca qualcosa che dovrebbe bloccare (ci si riferisce a questa evenienza come falso negativo)
The email Files
2) il filtro blocca qualcosa che non andrebbe bloccato (ci si riferisce a questa evenienza come falso positivo)
The email Files
Ora nel primo capitolo mi sono soffermato sul secondo punto come origine delle safelist, adesso come seconda uscita mi sembra opportuno di occuparmi del primo punto che dà origine al fenomeno delle “blocklist” .
Il problema che vogliamo indirizzare è quello del “falso negativo” che soffre di problematiche affini a quello del falso positivo di cui abbiamo parlato nel post precedente.
Certo un falso negativo può avere un effetto psicologico devastante sul ipreparato ricettore di tale oggetto:
Immaginiamoci la scena di sgomento quando un utente riceve una mail la cui sola presenza è origine di panico e terrore tremebondo. Immaginiamoci la giusta ira di coloro che a fronte dei potenti mezzi messi a disposizione dalla tecnica comunque riceve qualcosa che, nelle migliori ipotesi, non dovrebbe arrivare in casella.
Come proteggersi? possiamo fare qualcosa? Riusciamo a sopperire a tali tremebonde evenienze?
è difficile, ma per fortuna l’universo ci ha fornito uno strumento dai poteri quasi magici per affrontare il problema: le blocklist
Blocklist: cosa è
Il significato di una blocklist è quello di creare una serie di regole che bloccano le email basandosi sull’indirizzo del mittente.
Credo sia chiaro ai più che questo approccio ha senso solo se il mittente manda solo ed esclusivamente messaggi malevoli.
Questa evenienza è estremamente rara se consideriamo le email malevole: difficilmente un threat actor registra un dominio ed usa email dedicate in maniera statica.
Certo sarebbe bello se i cattivi fossero così gentili da usarci la cortesia di mandare messaggi malevoli usando email del tipo spam@evilactor.org ma, credeteci o meno, così non è.
Allora cosa finisce dentro una blocklist?
Email scappate ai filtri con basso profilo di pericolosità e media persistenza quali:
Email di spam
Email di marketing che l’utente si dimentica di aver sottoscritto
Questo tipo di messaggio è tipicamente segnalato dall’utente che, come è noto, ha poca dimestichezza o comprensione di cosa sia in realtà una email o la sua pericolosità.
Per evitare di generare errori queste blocklist andrebbero portate, esattamente come le safelist, il più vicino all’utente. In altre parole, gli utenti dovrebbero poter gestire in maniera autonoma (e solo per le mail a loro indirizzate ovviamente) questo livello di blocco.
Email scappate ai filtri con alto profilo di pericolosità ma bassissima o one shot persistenza quali
spoofing illegale di email o domini legittimi scappati
email provenienti da account legittimi ma compromessi
Purtroppo, la seconda categoria di email finisce molto raramente nelle blocklist ed il motivo sembra essere legato al fatto che riconoscere tali email non è facile nemmeno per un occhio semi esperto, figuriamoci un utente standard.
Ma anche nel caso queste fossero riconosciute è difficile che tali mittenti rimangano compromessi a lungo. I criminali tendo a cercare di aggirare blocchi elementari, ed il protocollo SMTP offre moltissime opzioni in merito.
Occorre quindi, onde evitare di bloccare email buone con quelle “sospette” o “malevole, una manutenzione attenta e continua di questo tipo di filtro.
Questo comporta in genere l’uso di quarantene (meglio se amministrative nel caso si sospettino attacchi pericolosi) che permettano eventualmente il rilascio del messaggio una volta verificato che non sia pericoloso.
Si ritorna ancora una volta al concetto, di difficile comprensione, che tutti i sistemi richiedono una opportuna manutenzione e monitoraggio.
Blocklist e Content Filtering
Lavorare con le sole email mittenti è di solito difficilmente scalabile ed efficace. In particolare al di furi di spam o newsletter, spesso ci si accorge che il tasso di errore da questo tipo di filtro è molto alto.
Per ovviare al problema, spesso alle blocklist tradizionali si aggiunge da parte di molti amministratori l’uso di content filtering più o meno avanzati.
L’uso del content filtering è più un problema di compliance che di “email security”, ma spesso questa tecnologia si presta ad un uso “improprio”.
A differenza di una blocklist che “ragiona” principalmente in termini di indirizzo o dominio di posta elettronica, e quasi per nulla sui contenuti del messaggio una blocklist che usa tecniche di content filtering fa riferimento, principalmente, a contenuti del messaggio: parole, URL, frasi…
Insomma la idea di base è:
non voglio ricevere email che contengano la parola “Cippirimerlo” quindi scrivo una regola del tipo:
se ne corpo della email o nell'oggetto appare la parola "Cippirimerlo" allora blocco la email.
Il ragionamento è evidententemente limpido e lineare. Certo occorre che “Cippirimerlo” sia usato solo in email malevoli e non in transazioni comunicative legittime (ok! ok! chi usa oggi come oggi “Cippirimerlo” se non un Hacker?).
Ma perché mai un attore malevolo dovrebbe imitare comunicazioni legittime, così rischia che la vittima non si accorga che è un attacco…
come? questo è lo scopo? aaaahhhhh
Cosa può andare storto?
Il problema delle blocklist anche in questa forma è analogo a quello delle safelist, nel senso che l’assunzione alla base è che un filtro statico possa indirizzare in maniera efficace ed efficiente un sistema dinamico come la posta elettronica.
Non voglio dire che questo non sia vero, ma solo che se fosse vero perché investire in sistemi di email security quando basta una semplice lista statica?
Diciamo che nel caso delle blocklist il problema risiede spesso nella gestione amministrativa dei sistemi di posta. Ho visto cose che voi umani … er..no ho visto però filtri estremamente complessi che utilizzano strutture che richiedono un livello di competenza elevato:
regular expressions
operatori booleani
orazioni e abluzioni
…
Purtroppo, questa profusione di esternazione tecnologica rimanda sempre al problema della staticità di questi filtri e della loro rapida obsolescenza.
Esattamente come nel caso delle safelist, infatti, le blocklist soffrono del problema che il filtro applicato ha senso solo nella finestra temporale in cui l’eventuale attacco viene erogato, dopo quel tempo il risultato è di rischiare di bloccare con il filtro email invece legittime.
é infatti impensabile, proprio come si diceva prima per le email mittente, che un attore malevolo utilizzi sempre la stessa esatta struttura di messaggio, sempre la stessa URL e via dicendo.
Anzi proprio per questi motivi la possibilità di catturare in maniera errata messaggi legittimi è estremamente alta.
Il workaround per evitare di incorrere in problemi in questo caso è di
modificare il filtro
cancellarlo
creare una safelist
…
Lascio ai più immaginare quale sia la soluzione meno indicata e vieppiù una delle più usate.
Blocklisting che fare:
cerchiamo di riassumere un po di indicazioni rapide che quindi possano aiutarci a gestire in maniera efficace le Blocklist
meno è meglio
Esiste un acronimo inglese che dovrebbe sempre guidare le nostre scelte: KISS (Keep It Simple Stupid.) e questo vale anche nella gestione di safelist e blocklist. Intendiamoci in questo caso la semplicità è legata, in primis, alla minimizzazione di queste liste in quanto più sono grandi maggiore è l’effetto negativo che possono avere sul sistema.
In particolare, gli elementi in blocklist se fanno riferimento ad email vanno considerati in funzione della loro pericolosità:
le email a bassa pericolosità (spam, marketing) possono essere bloccate, ma data la loro natura tali blocchi è opportuno che siano gestiti direttamente dall’utente finale in una sua lista personale alfine di minimizzare interferenze verso altri utenti.
le email invece di natura più pericolosa vanno gestite e monitorate con attenzione: è opportuno creare blocchi amministrativi e quarantene ma che siano monitorate costantemente per rilasciare le email legittime, i filtri di blocco dovrebbero essere rimossi non appena l’attacco si esaurisce.
Riportare al vendor del security gateway tutti gli incidenti
Per quanto possa sembrare tedioso aprire un ticket in caso di falso positivo e falso negativo è il sistema migliore per indirizzare e minimizzare certe problematiche.
E sia chiaro, l’apertura del ticket richiede anche il poter fornire un campione della mail completo di intestazioni. Senza questo la analisi diventaestremamente difficile.
Vorrei però che fosse chiaro che l’apertura di un incidente non sempre porta alla risoluzione desiderata, richiedere di categorizzare come email malevola una email che malevola non è non porta solitamente a generazione di un blocco generalizzato, contestualmente la modifica fatta da un vendor non può influire su filtri statici quali blocklist o safelist. L’apertura di un incidente, quindi, è solo una componente di un processo che deve comprendere la periodica revisione dei filtri statici quali safe e block list.
Non confidare ciecamente dei feedback degli utenti
Come per il whitelisting il blocklisting è tanto più efficace quanto i feedback degli utenti sono contestualizzati, analizzati e controllati. Il fatto che il megadirettoregalattico al cubo richieda un blocco o un safe non significa né che abbia ragione né che debba essere fatto. La sicurezza è una cosa che trascende le strutture gerarchiche proprio perché è al servizio del business.
Pianificare bene significa risparmiare tempo e risorse
Regole chiare, processi testati, analisi e verifiche cicliche servono anche nella gestione della posta elettronica.
Ragionare in anticipo su come gestire livelli di filtro associati alle varie tipologie di utenza, come gestire safe e blocklist dovrebbe essere parte integrante del disegno di un processo di gestione corretto ed efficace. Lavorare in perenne emergenza, aggiungendo e non manutenendo questi semplici aspetti rende i sistemi di posta estremamente vulnerabili.
E non esiste tecnologia che possa dare risultati se usata non correttamente.
Safelist e blocklist sono aspetti relativamente semplici e quindi sono un ottimo modo per far capire che “semplice” non vuol dire che non sia richiesta comprensione del fenomeno.
Nei prossimi post affronterò altri aspetti più complessi, ma mi sto chiedendo, quanti sanno come funziona la posta elettronica in realtà? Va a finire che negli email files mi toccherà anche cercare di spiegare almeno in maniera base come è fatto un messaggio di posta elettronica e come viene distribuito, altrimenti un sacco di cose mi sa che non si capiscono.
(se vi interessa qualcosa di specifico chiedete e vi sarà dato)
Ma del resto sono anni che sostengo che sapere qualcosa sui sistemi che usiamo non è proprio una cosa cattiva.
Ok sotto il cappello degli email files inizierò a scrivere riflessioni semiserie (come mio solito) sugli errori ed orrori di gestione della posta elettronica.
L’idea nasce da anni di militanza nel settore, ove ho realizzato 3 cose fondamentali:
la maggior parte degli utilizzatori non sa cosa sia e come funzioni la posta elettronica
la maggior parte degli amministratori non sa cosa sia e come funzioni la posta elettronica
i “cattivi” hanno capito benissimo come funziona la posta elettronica ed approfittano dei punti 1 e 2 per farne uno dei veicoli più efficaci ed efficienti di attacco.
Cercherò quindi in funzione di quel che mi passa per la mente, in maniera aperiodica e non regolare di scrivere quello che mi viene.
Oggi parlo di un argomento banale, il safelist o allowlist (una volta detto whitelist prima delle purghe del politically correct estremo).
Safelist: che cosa è
Iniziamo a capire di cosa parliamo.
Tutti gli strumenti di posta moderni hanno una serie di filtri più o meno evoluti che servono ad evitare che messaggi malevoli e pericolosi vengano consegnati alla mailbox dell’utente.
I motivi validissimi di questo approccio sono legati al fatto che:
gli utenti difficilmente hanno gli strumenti cognitivi per distinguere cosa sia pericoloso e cosa no (altrimenti non ci sarebbe questo successo devastante dell’uso delle email come veicolo di attacco)
la mail per le sue specifiche caratteristiche (vedetevi cosa sia l’SMTP, cosa significhi protocollo in chiaro, cosa significhi protocollo asicrono, cosa significhi protocollo unreliable cosa significhi avere doppie intestazioni tecniche e visibili…)
Il problema è che questi filtri non sono perfetti e si può incorrere in 2 spiacevoli estremi:
il filtro non blocca qualcosa che dovrebbe bloccare (ci si riferisce a questa evenienza come falso negativo)
il filtro blocca qualcosa che non andrebbe bloccato (ci si riferisce a questa evenienza come falso positivo)
Il punto 2 è quello di cui andiamo a parlare or ora.
Per evitare che i filtri non blocchino quello che non andrebbe bloccato tutti i sistemi e soprattutto tutti gli utenti invocano un rimedio che è stato identificato nel Safelosting.
Il procedimento è semplicissimo, si tratta di dire al sistema di non applicare questi filtri a specifici flussi di email. Il riconoscimento di questi flussi è di solito legato a:
uno specifico indirizzo di posta elettronica esempio: sonobuono@lasciamipassare.com
un dominio di posta elettronica come, ad esempio: @laciamipassare.com
Quindi una safelist consiste un una serie di voci: domini di posta e\o indirizzi che non vengono analizzati dai filtri di protezione del sistema
La base di questo approccio procedurale è basato dall’assunto: “non so cosa faccio, non ne capisco la tecnicalità dietro ma mi permetto di saltare, in pura incoscienza, i filtri di sicurezza confidando nella mia sopravvalutazione di essere capace di riconoscere eventuali rischi.”
Non intendo dire, con questo, che il safelisting sia una attività inutile, ma che va usata, per la sua natura di saltare i filtri di sicurezza, in maniera oculata e responsabile.
Ora non nego che le persone del marketing, sales, HR, Management assortito non abbiano la giusta preoccupazione di non avere mail importanti bloccate, il discutibile è che siano loro, privi delle competenze specifiche, a dettare vincoli che minano alla base la sicurezza di uno dei primi veicoli di attacco utilizzati dai threat actor.
Discutibile è anche il fatto che vi siano aspettative sulla posta elettronica ben lontane dalla realtà dello strumento. Aspettative legate, appunto, alla non conoscenza dello strumento stesso.
Se non si conosce uno strumento non lo si usa correttamente ne si è in grado di capire e valutare gli eventuali rischi connessi.
A fronte di questo oggettivo scenario, quindi, si decide arbitrariamente di mettere in sospensione i filtri? Non proprio la mossa più lungimirante se si guarda la cosa dal punto di vista della sicurezza informatica.
Ma allora che fare?
Falso positivo: ma di cosa si tratta davvero?
Il primo punto è capire cosa sia davvero un falso positivo:
Il falso positivo si ha quando i filtri di protezione individuano erroneamente un messaggio “buono” come “malevolo”
Raramente questa identificazione ha a che fare con la reputazione del mittente o la struttura delle intestazioni, proprio perchè stiamo parlando di falsi positivi. Questo significa che con grande probabilità la ragione del blocco è legata al contenuto del messaggio. Questo contenuto è per sua natura variabile e, a meno che non vi siano dei pattern ripetuti che incappano per qualche motivo nei filtri in essere, difficilmente provoca blocchi ripetuti e frequenti.
Esistono eccezioni a queste considerazioni, spesso newsletter o email marketing sono “malformate” (spoofing mittente, struttura HTML, componenti attivi, similitudine con campagne di attacco in corso e via dicendo)
A fronte di un evento puntuale, peròil safelisting pone una soluzione “statica” che blocca l’analisi dei contenuti di quei flussi di email in maniera permanente, questo di fatto aumenta sensibimente l’esposizione al rischio.
Procedimenti come il safelisting o il blocklisting non possono quindi non considerare le condizioni al contorno e specifiche del singolo messaggio. Il che non significa che non abbiano uso e scopo, ma che vanno gestiti in maniera coerente con la loro natura.
Safelisting: che fare
siamo onesti, in un mondo ideale con utenti preparati, consapevoli e capaci di gestire il rischio, emettitori di posta che fanno le cose per bene sapendo come si deve gestire lo strumento, gestori di mailserver e gateway che utilizzano approcci sensati e coerenti il safelisting non sarebbe quasi in uso.
Ma il mondo non è cosi, anzi.
La poca conoscenza del mondo delle email è imbarazzante, cosi come la scarsa comprensione delle esigenze di sicurezza di questo canale comunicativo quindi le liste di abilitazione ci accompagneranno per lungo lungo tempo.
Ma cosa fare allora per limitarne i danni?
Ci sono alcuni processi da mettere in piedi per gestire il safelisting che possono aiutare a diminuire la superficie di rischio.
Diminuire le voci in whitelist al minimo
questo sembra ovvio ma è il primo elemento da considerare.
Metter in whitelist tuttte le richieste provenienti dalle varie voci incoscenti dell’azienda non ha senso. Prima di safelistare qualcosa occorrerebbe verificare che non sia un evento ripetitivo. Un atteggiamento sensato consite nel sbloccare la email eventualmente bloccata, NON fare nessun safelisting ma iniziare a monitorare il comportamento di quel flusso di posta e procedere all’evetuale safelist solo in seguito a ripetuti blocchi errati.
Non mettere in whitelist interi domini
Se il safelisting espone ad un maggiore rischio, è evidente che inserire un intero dominio in whtelist significa aumentare il rischio in funzione del numerodi email generabili per quel dominio. Si deve considerare quindi che un dominio aperto significa tanti potenziali vettori di rischio.
Non mettere MAI in safelist domini di email pubbliche
Lo so che nessuno lo farebbe mai, ma allora perchè mi capita di vedere in queste liste robe tipo “gmail.com”, “yahoo.com”, “libero.it” e via dicendo?
Le email consumer free sono un veicolo ideale per sviluppare in maniera semplici attacchi anche sofisticati, il solo richiedere di “liberare” un tale dominio è dimostrazione più che evidente che il richiedente non ha idea di cosa sia la posta elettronica ne come si usi. Non importa se è il figlio del direttore HR, il cognato del vicepresidente del marketing, o il cane dell’amministratore delegato. Semplicemente queste richieste devono essere negate fermamente senza se, senza ma e senza forse. In alternativa ci si fa dare una bella mail che impone il cambio da poter mostrare al soggetto al primo attacco ransomware dicendo: “te lo avevo detto ma tu…” 🙂
Se proprio devi fare safelist almeno limita i danni
Uno dei primi concetti che impari quando si parla di sicurezza è che minore è la superficie di esposizione minore il rischio. Essendo il safelisting una procedura che espone a rischio gli utenti è buona norma spostarla il più vicino al richiedente in maniera da ridurre la esposizione per gli altri utenti.
Mi spego: abilitare un mittente a bypassare i filtri per l’intero numero di utenti della azienda non ha molto senso se la richiesta proviene da una risorsa specifica. Molti sistemi oggigiorno consentono di creare policy specifiche per singoli utenti e gruppi di utenti ristretti. Una scelta opportuna è operare safelisting a questi livelli piuttosto che per tutta la organizzazione.
Ha senso spostare il safelisting quindi nella struttura più vicina al richiedente, utente o gruppo di utenti che sia.
Sopratutto in caso di gestioni estremamente statiche del safelist questo consente di controllare un minimo la superficie di rischio.
Un safelist NON è per sempre
Diciamocelo chiaro, non esistono motivi per tenere una lista che permetta l’ingresso di “la qualunque” per sempre in maniera immutabile. Già le considerazioni precedenti dovrebbero aver aperto un minimo di consapevolezza sul fatto che il safelisting non è una panacea dal punto di vista della sicurezza.
Per evitare che queste liste crescano a dismisura e calcifichino email e domini in maniera perenne è opportuno periodicamente procedere ad una revisione delle voci della lista.
Questo significa che dopo un certo periodo di tempo sarebbe opportuno eliminare le voci (in modalità FIFO, First In First Out). Difficilmente gli errori, se la piattaforma di filtering è gestita correttamente, si ripeteranno.
Sapere come usare i propri strumenti non è una brutta cosa.
Mi si conceda una ultima battuta.
Come tutti gli strumenti anche la posta elettronica ha le sue specificità che andrebbero conosciute da chiunque la utilizzi, la pessima idea di sapere come usarla e non avere bisogno di formazione è tanto stupida quanto, purtroppo, radicata.
E non si pensi che la cosa sia limitata ai soli utenti o al magnifico management, spesso anche chi si occupa di IT e persino di posta non ha le competenze corrette per gestire questo strumento al meglio.
Ne sia un esempio questa domanda:
quanti sanno cosa siano
SPF
DKIM
DMARC
e quali siano vantaggi e debolezze di ogniuno di questi protocolli di autenticazione della posta?
Ok, lo ammetto, oggi è il mio ultimo giorno da 55enne, da domani si sblocca il livello 56.
Se tra le cose buone di questo traguardo è che lo ho raggiunto, vi è anche il fatto di non essere obbligato a fare sunti o valutazioni della vita sin qui trascorsa, queste cose le lascio ai cinquantenni che ancora si credono giovani 🙂
Tra le cose cattive c’è che da domani, nei selettori dell’età delle ricerche online, sono definitivamente in area senior (di solito il limite superiore è 55) e quindi da domani mi devo aspettare marketing dedicato a montascale, dentiere, pannoloni e via dicorrendo.
L’unica cosa che probabilmente non cambierà è il phishing e lo spam a sfondo dating, che comunque da una certa soddisfazione visto il mumero di gente che mi vuol regalare soldi e il numero di donne che mi cercano e che abitano qui vicino (e dire che non me ne sono mai accorto).
Che cosa è cambiato tra questo compleanno ed il precedente
Sebbene non debba fare valutazioni viene spontaneo fare distinzioni tra il me a 55 ed il prossimo me a 56. E devo dire che non ci vedo differenze di sorta, non almeno sostanziali.
Certo la psoriasi è sempre li con effetti anche fastidiosi (leggasi fimosi, cisti ed altre amenità), il mal di schiena aumenta e, stranamente, non divento più atletico neanche dopo intense sedute sul divano di fronte a qualche sport.
Arrivo quindi a questo fine 55 con qualche difficoltà. A parte il fisico che non regge più come una volta (da lanciatore di coriandoli professionsita adesso al massimo posso essere hobbista) adesso dovrei iniziare a fare attività fisica dedicata, come dare una occhiata ai cantieri con le braccia dietro la schiena.
Raccolgo le info e mi reparo per gli allenamenti.
Ad onor del vero devo anche dire che lo snooker in TV non è proprio il massimo per incrementare la forma fisica, ma almeno vedere AEW e WWE mi ricorda i bei tempi quando mi divertivo anche attivamente. Ovviamente sempre seduti sul divano.
Dal punto di vista sportivo i 55 mi hanno regalato l’europeo, 40 medaglie alle olimpiadi, non che io abbia meriti di sorta, ma almento alcuni pezzi li ho potuti vedere in 4K, il che dovrebbe darmi un plus sugli allenament no? 🙂
Per il resto non ci sono state grandi cose, e non ho proiezioni particolari per i miei 56. Non vedo un aumento ne di intelligenza da parte dell’umanità ne di un aumento di tolleranza mia a fronte di affermazioni deliranti di “coloro che sanno”:
cosa penso di voi, si anche di te!
complottisti,
novax,
terrapiattisti,
ditttaturasanitaristi,
grenpassshoahisti,
nomascherinisti,
sinistristi,
destristi,
quellideipoterifortisti,
quelli che lo dice quel premio nobel e quindisti,
antiscientisti e scientisti,
virologisti,
allenatoristi,
epidemiologisti da tv o social
…
Un anno di pandemia, pandetua
La pandemia non ha aiutato la mia ricerca di relazioni sociali, ma devo dire che almento lo scorso 16 settembre ho festeggiato con #quellidelfascicolop il grido
se non sapete cosa si festeggi il 16 settembre non vi preoccupate, si tratta di una festa Messicana quindi non siete tenuti a saperlo, anche se il saperlo vi farebbe onore.
l’autore
Come tutti i momenti di crisi però la pandemia ha mostrato il peggio ed il meglio (ma sopratutto il peggio ma anche il meglio), delle persone.
1965 – Che annata ragazzi
Certo da immundi al vaccino che in(o)cula il chip che ci controlla via 5G di stupidate se ne sono sentite (e se ne sentono) in quantità paraindustriale, ma ho fatto voto di cercare di non intervenire quando leggo certi commenti, inutile cercare di dare senso storico, contesto o semplice matematica elementare.
E, chiariamoci, per uno come me che nella polemica ci sguazza come un paperottolo è stato uno sforzo notevole. Ma ogni tanto devo anche pensare a come gestire meglio le risorse limitae che possiedo, anche mentali.
Se devo farmi un augurio per il mio 56 anno, che non debba più leggere le cazzate stratosferiche legate al covid_19.
Ora non dico opinioni diverse, dico proprio le cazzate. Lo so chiedo troppo, ma sono un inguaribile sognatore.
Del resto questo anno di pandemia ha coinciso anche col ricovero di changuis in comunità, quindi ho avuto cose molto più serie di cui preoccuparmi.
Anzi visto che a settembre ci sarà il cambio a 18 anni, molte cose dovranno cambiare, e la cosa è semplicemente terrorizzante. vedremo i 56 cosa mi chiederanno di sopportare per supportare Changuis.
Per i curiosi si sono vaccinato (pfizer biontec) ed ho il greenpass, è stata una scelta consapevole dei rischi legati a questo vaccino che mi sono assunto liberamente con considerazioni che, permettetemelo, sono però mie e che mi tengo per me.
Lavoro ed Informatica
La fine di questi 55 sono costellati da momenti di pura ilarità nel campo della mia professione. Solo Agosto la PA ci ha donato la serie comica Magnum PA con i primi 3 episodi:
le disavventure della regione lazio: i misteri di broken backup,
le disavventure della regione lombardia: hot stuff,
della regione toscana: siamo in pandemia prendersi un virus è normale
non vedo l’ora di vedere le prossime puntate. E poi dicono che occuparsi di sicurezza informatica è noioso.
Certo se dovessi tirare un resoconto dei miei 55 ho avuto, purtroppo, la triste conferma che la tendenza di aprire la bocca in maniera disgiunta dal cervello non siaccompagna solo ai temi citati prima ma anche in questo che, in teoria, dovrebbe essere “tennico”.
Purtroppo la situazione familiare mi ha limitato molto nelle attività, a parte le mie scivolate linkediniane ho purtroppo dovuto limitare il tempo a disposizione per scrivere, ma spero di riuscire a riprendere tra un po. del resto questo è un primo tentativo (non scrivevo sul mio blog da un sacco di tempo).
Cercherò di essere più presente, per me ovvio 🙂
Che faccio domani:
Non cercatemi non garantisco risposte, ho preso il giorno di ferie e mi concedo un ristorante con la mia signora. non offendetevi quindi se non rispondo. nNon condivido il ristorante in anticipo perchè non amo firmare autografi, la fama è una croce lo so!
Ma poi magari dirò se mi sono trovato bene al ristorante.
Ultime considerazioni
Di Afghanistan, Information Security probabilmente scriverò più avanti. Di vaccini, pandemia e green pass invece no, mi rifiuto. Da un lato perchè ho le mie opinioni ma non sono un esperto (lo ammetto non sono un tuttologo) dall’altro perchè nel 99% delle cose che ho letto trovo che l’approccio sia (da tutti i lati) esattamente quello che ritengo non si dovrebbe mai fare: dare valori morali preconcetti, usare un metodo antiscentifico, usare riferimenti e citazioni “ad cazzum” (“a mentula canis” per i latinisti) e non confrontarsi mai sulla realtà ma su pezzettini parziali. Esattamente come politica, geopolitica, information security
RIP Gino
Vorrei terminare con un pensiero per Gino Strada.
Non c’entra col mio prossimo compleanno, ma centra molto con rispetto ed ammirazione.
Esiste gente che parla, e gente che fa. Gino era uno che faceva, ma nella logica delle contrapposizioni ideologiche non si può dare onore.
Purtroppo al solito il mondo social è riuscito a dare il peggio di se, e se non posso certo aspettarmi che soggetti come Gasparri mostrino dispiacere (sarebbe stato quantomeno imbarazzante ed ipocrita), certe grida di ammirazione pelose bipartisan ora sono per lo meno curiose da soggetti che non hanno mai dismostrato affinità alcuna con il suo lavoro.
Mah sicuramente loro avranno ragione, visto che io ho sicuramente torto.
Cosa hanno in comune i click day, i disastri informatici dell’INPS, Immuni o le interfacce per registrarsi per sperare in un vaccino anticovid?
Questi sono tutti aspetti dell’approccio italico alla digitalizzazione, un approccio che si basa su 3 pilastri granitici:
evitare nella maniera più assoluta di contestualizzare l’idea digitale
il digitale è la replica pedissequa di processi mal disegnati analogicamente
nessuna progettazione tiene in conto la possibilità di errore ed i relitivi processi correttivi
In altre parole la digitalizzazione è demandata ad ambiti che di digitalizzazione nulla comprendono, da cui i disastri annunziati di cui nessuno, per altro, sembra stupirsi.
Il problema risiede in una totale apparente mancanza di comprensione di cosa voglia dire la digitalizzazione che spazia dal disegno dei processi, all’analisi dei presupposti per sfociare infino alla relativa implementazione. Quello che in Italia viene spesso “spacciato” per digitalizzazione è quindi in realtà una accozzaglia di interfacce digitali per accedere a servizi disegnati non per la digitalizzazione.
Insomma dire che uso la email, non significa che io abbia adottato una strategia comunicativa digitale, cosi come essere su facebook non significa essere competenti digitalmente e se questi sono i prerequisiti di chi idea e disegna questi processi siamo alla frutta.
Questo articolo nasce da un mio post su linkedin che riporto:
Poi magari ci scrivo un articolo sul mio blog (che diserto da troppo) ma posso dire che vedere dei geni che pensano di offrire l’iscrizione alla vaccinazione per gli ultraottantenni via web dimostra quanto niente si sia capito cosa volglia dire la digitalizzazione in Italia? Capiamoci, chiaro possono intervenire intermediari (figli, farmacie, medici di base ma mica tutti e non ovunque) ma il problema nasce nel disegno stesso del progetto. 1) vogliamo iniziare a tenere conto nella digitalizzazione degli utenti che devono fruire un servizio? 2) vogliamo considerare gli utenti per le loro effettive caratteristiche sociali e anagrafiche? 3) vogliamo tener conto delle cosidette condizioni al contorno ( cosi per citarne due: livello di competenze digitali, digital divide) 4) introduciamo quindi nel disegno del processo il privacy e security by design e by default? 5) introduciamo controlli e metriche per verificare il servizio 6) monitoriamo gli output e mettiamo in piedi un servizio che consenta change correttive se serve? 7) vogliamo capire che la digitalizzazione va ben al di la dello scrivere bene o male il codice?
o continuiamo a disegnare processi alla ca..volo, e chiamiamo digitalizzazione l’accesso digitale a servizi che non sono pensati per il digitale?
cercherò quindi di sviluppare questi punti per esempi e esperienza.
Processi digitali e processi analogici
Il primo punto che mi piace chiarire che “processi digitali” ed “processi analogici” non sono la stessa cosa, e inserire in un processo una qualsiasi interfaccia digitale non significa che si sia fatta digitalizzazione.
Se cosi non fosse allora qualsiasi componente digitale sarebbe digitalizzazione, in questo caso visto che circa l’80% di quello che si scrive si fa via interfacce digitali (computer, laptop) allora si avrebbe la idea che tutto sia già digitalizzato. In realtà le cose non stanno proprio così.
Quello che si intende per digitalizzazione è la trasformazione dei processi analogici con equivalenti digitali con lo scopo di:
rendere le cose più efficienti tramite integrazione ed eliminazione di ridondanze
poter offrire più servizi al cittadino
semplificare l’accesso alle risorse da parte del cittadino
questo richiede la presa in carico di un intero processo analogico e trasformarlo in maniera conforme agli strumenti digitali disponibili tenendo presente:
quale sia lo scopo del processo
che risorse siano necessarie
quali siano gli equivalenti digitali da implementare
chi sono gli utenti cui si fa riferimento.
sembra facile ma i risultati italici sono sempre improntati al disegni di mio cuggino. L’equivalente digitale, ad esempio, spesso richiede che sia messo in piedi un processo di dematerializzazione del supporto cartaceo.
Basta avere esperienza di PA per sapere che la carta non solo rimane ma si moltiplica, si pensi alla autocertificazione per il covid che NON era ammessa in forma digitale, insomma dovevi avere la carta (sigh) ma il modulo lo scaricavi in PDF (tradotto computer, stampante) stampavi su carta e presentavi a richiesta (ok se non potevi la cosa poteva essere compilata dal rappresentante delle forze dell’ordine, insomma duplichiamo…)
Mio Cuggino e le ricette digitali in provincia di Pavia
Siccome mi piace fare esempi concreti, in tempo di lock down il medico offriva le ricette in formato digitale. vediamo il processo
noi lo richiedevamo via WhatsApp
il medico generava la ricetta sui suoi sistemi
ci inviava via WhatsApp un immagine che conteneva codice
con questo codice andavi in farmacia
davi quel codice e nome dell’assistito
il farmacista lo immetteva a sistema
stampava a ricetta
ricaricava la ricerca in un altro sistema con un lettore a codice a barre
caricava anche i codici a barre dei medicinali
ti chiedeva se volevi mettere la tessera sanitaria
stampava lo scontrino
poi alla fine i farmacisti credo debbano stampare le resultanze di queste ricette per la regione, ma non metterei la mano sul fuoco.
Cosa c’è di sbagliato in questo processo? è vera digitalizzazione?
Esistono una serie di problemi evidenti persino senza scomodare security, privacy ed uso di un sistema di messaggistica …
Perchè se ho un codice digitale per un documento lo devo stampare e ricaricare? davvero non è possibile disegnare i sistemi ab initio per essere integrati senza il passaggio cartaceo?
I talloncini adesivi con il codice a barre vengono messi sulla ricetta cartacea, la lettura del codice ne crea un equivalente digitale a sistema (ricetta e talloncini), ma sono univoci, che bisogno c’è di questa duplicazione?
Insomma tutto il processo è stato disegnato non per tener in conto gli scopi primari della digitalizzazione (efficientamento, semplificazione, miglior servizio all’utenza), ma apparentemente per aumentare i livelli di complessità operativa, cosa che la digitalizzazione dovrebbe indirizzare e risolvere.
Si può osservare che la parte cartacea serva per offrire una maggiore sicurezza ai controlli, ma se cosi fosse mi verrebbe da chiedermi ma allora avete idea che sicurezza, tracciabilità sono parimenti ottenibili digitalmente?
Insomma un processo cosi complesso lo avrebbe sicuramente disegnato bene anche mi cuggino, probabilmente alla metà del prezzo del cuggino che lo ha ideato.
Questo esempio dimostra come pensare un processo digitale non sia a semplice e pedissequa replica di cosa si farebbe analogicamente.
Ma visto che stiamo parlando di digitalizzazione prendiamo un’altro aspetto preso ancora dalla esperienza personale:
Mio cuggino e la adesione al processo vaccinale della regione Lombardia
La Lombardia è considerata una eccellenza italiana nei confronti della digitalizzazione.
la Lombardia spicca in italia sia per implementazione della digitalizzazinoe che per competenze digitali.
Quindi trovo strano, a fornte di tale e specchiata eccellenza, che capiti quanto segue:
Mia madre è ultraottantenne e vorrebbe fare il vaccino anticovid. Ora noi non viviamo nello stesso paese, quindi non c’è un contatto diretto. Mia Madre è una classica ultraottantenne, con nessuna competenza digitale (neanche gli SMS per intenderci) con problemi di vista e di udito.
Nella sua ingenuità senile, legata probabilmente ai ricordi della sua giovinezza quando in un mondo analogico il dottore “della mutua” visitava i pazienti anziani a casa, ha pensato di chiedere al medico via telefonica cosa doveva fare per il vaccino.
La risposta è stata che i medici di base non possono seguire queste cose in quanto sono troppo complicate (? – forse faceva riferimento ai carichi di lavoro) e che aveva 2 alternative o chiedere se la farmacia offriva questo servizio o lo poteva fare facilmente via web.
Ora chiedere a mia madre di usare “l’internet” è come dirle di discutere di una equazione differenziale alle derivate parziali mentre cammina su di un filo di lana teso tra due grattacieli durante una d’uragano mentre è in corso un terremoto con relativo tsunami.
Ha quindi telefonato in farmacia, che ha risposto che lo avrebbero fatto volentieri ma siccome i sistemi erano sovraccarichi avrebbe dovuto richiamare.
Visto che per amor filiale ogni tanto la chiamo, avevo gia preventivato che avrei dovuto supportarla, e avevo già cercato il famigerato link del servizio della ragione lombardia.
il sito al momento della scrittura del post
Ho quindi effettuato per suo conto la registrazione (sono stato anche fortunato nelle tempistiche).
Cosa c’è di sbagliato in questo processo?
Uno dei punti fondamentali del disegno di un processo è capire come gli utenti coinvolti vi possono interagire.
Ora non considerare le competenze digitali della fascia di popolazione che si vuole indirizzare è, per essere gentili, una cugginata. Pensare che la maggior parte degli ultraottantenni abbia la capacità di trovare il sito (vi raccomando il portale della regione lombardia) è semplicemente stupido. E questo indipendentemente dalla semplicità con cui è stata scritta l’interfaccia (su cui potrei esprimere commenti).
Ora se l’idea era sin dall’inizio quella di usare un intermediario (familiare e\o farmacia) bastava dirlo, ma vorrei capire se non ci fossero stati i familiari a supporto quanto facile sarebbe stato questo processo. E capiamoci, facendo riferimento anche al rapporto DESI citato prima, non è detto che gli elementi familiari siano in grado di dare supporto…usare tiktok o facebook (ancora una volta) NON significa avere competenze digitali che ti consentano di trovare quella pagina.
Insomma persino nella eccellenza lombarda la digitalizzazione è in mano ai cuggini.
E potrei, se fossi bastardo, menzionare che se fai un errore di immissione non hai una interfaccia di correzione. Una volta che hai dato l’ok quello che è fatto è fatto, ma siccome sono buono mi trattengo.
Mio cuggino ed il Click Day
Lo abbiamo sperimentato in molti, la eccitante sensazione del click day…ci vai e tutto va a rotoli, interfacce bloccate, servizi malfunzionanti, security e privacy assolutamente inesistente, tempi biblici….
Il 2020 ci h dato notevoli soddisfazioni, il click day è la dimostrazione che la digitalizzazione è in mano ai cuggini dei cuggini per diversi motivi. Al di la del fallimento consistente dei queste iniziative dal punto di vista tecnico che tutti abbiamo in qualche modo sperimentato, vorrei fare alcune osservazioni su come questi sistemi siano pensati e perchè sono assolutamente ingiusti.
La idea sottesa a questi click day è dare una finestra temporale dove chi è avente diritto (o presumibilmente ha diritto) può fare richiesta. L’idea è ovviamente di gestire gli accessi in linea FIFO (First In First Out), una solta di filtro meritocratico dove il merito è la velocità.
Ora la idea stessa del click day è discutibile proprio per gli assunti precedenti: io faccio una selezione arbitraria legata alle competenze digitali.
Se l’oggetto fosse inerente la digitalizzazione potrei persino capirlo, ma sul bonus monopattini? perchè arbitrariamente danneggiare chi non ha competenze digitali?
OK OK magari è voluto per invogliare la acquisizione di tali competenze nella popolazione dei monopattinatisti, metodo discutibile, pedagogicamente inutile ed ottuso, ma “comprensibile”.
Ora anche supponendo che sia eticamente corretto il filtro di cui sopra, e che tutto sia stato disegnato correttamente e funzioni le liste fifo determinerebbero l’ordinamento delle richieste, peccato che su internet non sia possibile garantire l’ordine di arrivo temporale basandosi sul ordine temporale di partenza.
Mi spiego perchè ho visto l’occhio pallato … se due tizi si mettono davanti al computer e si connettono ad un portale per immettere le informazioni non è detto che chi ha cercato di connettersi prima sia quello che si connette prima, e non è detto che il processo di elaborazione della immissione sia paritetico.
Diversità di banda, di capacità elaborativa dei terminali di accesso, congestione della rete possono alterare questa gara, perchè di gara si tratta.
Ora se possiamo considerare in carico dell’utente la sua capacità elaborativa (questionabile per diversi motivi) sicuramente è al di fuori del controllo dell’utente la prestazione della connettività. Per esemplificare è come se si chiedesse di arrivare primi in una gara in cui alcuni sono vicini con autostrade intonse e guidando una Ferrari, mentre altri hanno stradine di campagna e distanze elevate (e poi usala la Ferrari).
Se aggiungiamo alla equazione il fatto che le risorse cui accedo sono una discriminante arbitraria delle prestazioni la frittata è fatta, alla faccia delle pari opportunità
Il concetto stesso di FIFO richiede quindi ripensamenti, ad esempio la lista potrebbe essere densa ma non ordinata (permettendo piazzamenti in parimerito in funzione di una finestra temporale che tenga conto delle possibili ragioni di latenza lasciando vuote le posizioni successive relative).
Insomma una apparente buona idea cugginesca (il click day) si dimostra già come idea fallace ad una minima analisi, se poi aggiungiamo i difetti di implementazione, prestazione security e privacy … abbiamo a digitalizzazione all’italiana.
Concludendo?
Ho voluto esprimere le mie perplessità sull’approccio alla digitalizzazione perchè in molti casi il problema non è di security, sizing o coding, ma proprio di approccio al processo.
E se non si è in grado di disegnare un processo digitale correttamente , le atre cose sono difficilmente considerate nella maniera corretta. Come a dire che mio cuggino se disegna male dall’inizio è inpensabile che faccia bene ilresto.
Va da se che anche un coding eccezionale fallisce se il contorno è mal disegnato.
E non ho voluto parlare della digitalizzazione della giustizia, dei servizi PA per evitare le parolacce …
Quando si parla di digitalizzazione occorrerebbe innanzi tutto capire cosa voglia dire, purtroppo troppo spesso ci si sofferma sul dettaglio e non sulla “big picture”, col risultato che anche il “probelm setting” per indirizzare la causa del problema risulta inefficace.
Oggi si parla tanto di digitalizzazione, la speranza è che si faccia vera digitalizzazione e non offrire interfacce digitali per servizi pensati in analogico, altrimenti sarà come la pec oramai quasi obbligatoria in tanti servizi PA ma anche interfaccia obbligatoria per le aziende che però non ha obbligo di monitoraggio e quindi risulta spesso piena o non letta (e non ditemi che non vi è capitato) ….
