Garante & email: se 7 giorni vi sembran pochi

Non ce la posso farcela!

Ho appena finito di “elogiare” l’AGICOM per l’ennesima implementazione a mentula canis del “piracy shield de no artri”, che mi trovo a dover confrontarmi con la ennesima trovata italica, questa volta del GPDP.

Provvedimento del 21 dicembre 2023 – Documento di indirizzo “Programmi e servizi informatici di gestione della posta elettronica nel contesto lavorativo e trattamento dei metadati” [9978728]

Intendiamoci io capisco che occorra imporre delle limitazioni per legge sull’uso distorto e non autorizzato di dati, e che queste non necessariamente siano coerenti con gli sviluppi tecnologici, ma ogni tanto metterci un po di cervello non guasterebbe. Qui il riferimento più che al garante va ai DPO e responsabili aziendali che, per mettersi in una “posizione sicura” interpretano certi indirizzi in maniera rigida e decontestualizzata.

Allora vediamo di cosa si tratta questa volta:

A seguito di alcune sentenze, e alle considerazioni che già il garante aveva espresso in passato, il garante stesso si è posto il problema dei cosiddetti “metadati” della posta elettronica.

I metadati

I metadati sono, fondamentalmente, tutto quello che concerne la descrizione di un messaggio di posta elettronica, fatta eccezione dei contenuti. Vengono ricavati durante la transazione SMTP (il protocollo che serve al trasferimento dei messaggi della posta elettronica), le intestazioni tecniche del messaggio di posta elettronica stesso (fate riferimento ai miei Email files per capirne di più), e i log dei nodi attraverso cui passa il messaggio fino al raggiungimento (o meno) della casella di posta dell’utente.

Questi dati, se non gestiti correttamente ed usati in maniera non legale, possono dare adito a processi che violano la riservatezza di mittente e destinatario, e possono consentire un monitoraggio non legittimo, ad esempio, delle attività dei lavoratori ai sensi dello statuto dei lavoratori.

I metadati quindi possono e devono essere oggetto di attenta considerazione.

Ma

Ma, ettepareva, c'è un ma.

io me

I metadati sono anche fondamentali per il funzionamento delle soluzioni che gestiscono la posta, e tra queste esigenze vi è una roba che, sempre per esigenze anche delle normicciuole sulla protezione dei dati, si chiama sicurezza.

Esiste quindi un esigenza di capire quanti metadati vanno tenuti per preservare le esigenze di riservatezza verso quanti servano per il corretto funzionamento dei sistemi.

Il garante ci da una prima risposta: 7 giorni

il garante

Infatti, il Garante ha analizzato (in precedenti provvedimenti) quale fosse il tempo di conservazione dei metadati compatibile con l’attività di raccolta e conservazione degli stessi metadati necessari ad assicurare il funzionamento delle infrastrutture del sistema della posta elettronica e che rispettasse il principio di accountability e il comma 2 dell’art. 4 dello Statuto dei Lavoratori. La conclusione del Garante è stata – appunto –  in poche ore o ad alcuni giorni, in ogni caso non oltre sette giorni, estensibili, in presenza di comprovate e documentate esigenze che ne giustifichino il prolungamento, di ulteriori 48 ore.

Sarei curioso di capire quale sia la componente “tecnica” sottesa a tale valutazione. e metto le virgolette a ragion veduta.

Limitarsi a 7 giorni di metadati è, di per se, una stupidata galattica. Non me ne voglia il garante ed i suoi illuminati esperti, ma evidentemente non hanno mai avuto a che fare con la posta elettronica sia dal punto di vista gestionale che tecnico, e si vede.

Sono pronto a discutere della cosa con qualsiasi “esperto” che ritenga che i 7 giorni siano piu che sufficienti.

Vi sono ottime ragioni per considerare tale finestra temporale inadatta, facciamo qualche esempio:

• Cosa succede se occorre fare ricerca di un messaggio, si pensi ad esempio a problematiche legali in cui le email possano essere oggetto della contesa, risalente a problemi anteriori ai 7 (+2) giorni?
• Cosa succede se occorre fare troubleshooting di problematiche che si protraggono nel tempo e che richiedono, ad esempio, l’analisi di log di server e MTA?
• Cosa succede se occorrono informazioni per monitorare i livelli di sicurezza del sistema?
• Cosa succede se per motivi di sicurezza si cerca di capire quale sia la esposizione al rischio degli utenti in funzione delle metriche di attacco che avvengono sulla posta medesima?

Potrei continuare, ma sono sicuro che i più (voglio essere positivo) hanno capito la problematica.

Ma siccome sono duro di comprendonio mi chiedo:

Tali metadati hanno esigenze di vita diverse se si parla di un Mail Server o di un security gateway?  

Le due cose solo marginalmente coincidono (la condivisione, ad esempio, del protocollo SMTP e la modifica degli Header di posta)

Alcuni dei metadati citati sono, quantomeno, da meglio definire ad esempio:

Cosa si intende per mittente? il campo “from: ” nella intestazione tecnica o il campo “from: ” in quella visibile?

No signor tenente non coincidono.

e l’ip mittente si intende quello dell’ultimo HoP o quello indicato come iniziale?

E cosi il dominio di provenienza (HELO/EHLO) quale è?

Ovviamente se fossi un pessimo soggetto potrei ricordare che l’alterazione, o la costruzione malevola, di questi metadati è alla base di diversi attacchi perpetrati attraverso la posta elettronica, e siccome sono, fondamentalmente, un pessimo soggetto lo ricordo

I metadati della posta elettronica sono spesso modificati ed alterati da attori malevoli al fine di perpetrare attacchi attraverso tale canale di comunicazione

un cattivo soggetto

La conseguenza di questo piccolo punto è, quindi, che il monitoraggio di questi elementi è fondamentale per questioni di gestione della posta, troubleshooting di problematiche e analisi di sicurezza. Pensare che tali esigenze possano essere ricondotte a un 7+2 giorni significa non avere la benchè minima ne pallida idea della realtà tecnica e delle esigenze di sicurezza.

E quindi?

Li vedo i puristi della “privacy” già si ergono:

le questioni tecniche non devono prevalere sui legittimi diritti e protezione delle lavoratrici e dei lavoratori

i DPO duri e puri del GDPR e gli avvocati indefessi dello statuto dei lavoratori

In realtà il garante ha un problema: far si che i metadati siano usati in maniera legittima e consapevole da parte dei soggetti.

Il garante stesso da la soluzione al di la della delirante richiesta dei 7+2 giorni:

I datori di lavoro che per esigenze organizzative e produttive o di tutela del patrimonio anche informativo del titolare (in particolare, per la sicurezza dei sistemi) avessero necessità di trattare i metadati per un periodo di tempo più esteso (quindi tutti salvo rarissime eccezioni quali gli esperti del garante), dovranno espletare le procedure di garanzia previste dallo Statuto dei lavoratori (accordo sindacale o autorizzazione dell’ispettorato del lavoro).

L’estensione del periodo di conservazione oltre l’arco temporale fissato dal Garante può infatti comportare un indiretto controllo a distanza dell’attività del lavoratore ma non per il metadato in se, ma per l’uso illecito effettuato di dali dati.

Del resto se vogliamo estendere la vexata quaestio al piu generico mondo della posta elettronica, compreso, quindi, il messaggio intero, potremmo per estensione pensare di chiederci se è possibile tenere nella casella di posta dell’utente un messaggio per piu di 7+2 giorni.

Attenzione che in pancia a quel mail-server le informazioni sono, almeno negli assunti indicati dal garante per indicare il metadato, tutti presenti.

La eliminazione, quindi, dei metadati comporterebbe la necessaria eliminazione dei messaggi archiviati nel server nella casella dell’utente.

Certo possiamo fargli creare archivi locali, ma questa non è certo una soluzione che si accompagni alla sicurezza (e se volete ne possiamo parlare).

Spieghi il garante allora agli utenti il razionale di tale vincolo e limitazione 🙂

Insomma ad essere chiari le finalità primarie per tenere i metadati per oltre 7+2 giorni, ovviamente, restano troubleshooting di problemi e la sicurezza informatica e i necessari accertamenti da fare a seguito di data breach o comunque incidente sulla sicurezza informatica. Elementi più che validi per ritenere che le indicazioni date siano non sufficienti ne adatte al mantenimento e gestione dei sistemi di posta elettronica.

Ma, occorre dire, il garante stesso non indica un vincolo assoluto nei 7 giorni, ma richiede che retention più lunghe siano poste in essere con la garanzia del rispetto delle tutele previste dal GDPR e dallo statuto dei lavoratori.

Non provateci a dire che non ve lo avevo detto.

Ciao ciao AirVPN, grazie Piracy Shield

Friday rant del mercoledì:
#fridayrant #quellidelfascicolop #quellascemenzadellasera

io comprendo la esigenza di bloccare la pirateria dei contenuti legittimamente offerti dalle piattaforme che li hanno acquistati, ma talvolta la cura proposta è semplicemente aberrante.

Ogni riferimento al nostro Piracy Shield, creata dalla mai doma #AGICOM (ica) è dovuto: l’ennesimo esempio di come implementare male una pessima idea.

Non devo neanche scriverci, tutto è già stato scritto qui da #AirVPN annunciando che lascia il mercato italiano.

Il cosiddetto “Scudo Italiano Anti-Pirateria” è un quadro normativo con regolamento attuativo dell’AGCOM (Autorità Italiana per le Telecomunicazioni) che obbliga gli operatori che offrono servizi in Italia a bloccare l’accesso ai servizi finali attraverso il blocco IP e/o l’avvelenamento DNS. L’elenco degli indirizzi IP e dei nomi a dominio da bloccare viene stilato da organismi privati ​​autorizzati dall’AGCOM (attualmente, ad esempio, Sky e DAZN). Questi enti privati ​​inseriscono le blocking list in una piattaforma specifica. I blocchi devono essere imposti entro 30 minuti dalla loro prima comparsa da parte degli operatori che offrono qualsiasi servizio ai residenti in Italia.

Non esiste alcun controllo giurisdizionale e nessun controllo da parte dell’AGCOM. Il blocco deve essere eseguito inaudita altera parte e senza possibilità di reale rifiuto, anche in caso di errore manifesto. L’eventuale opposizione della parte lesa potrà essere proposta solo in una fase successiva, dopo l’imposizione del blocco.

Posted Last Monday at 6:45 PM

Hello!

We regret to inform you that we will be discontinuing the service to residents of Italy as of February the 19th, 2024.
From the above date, any user registering on the platform must declare that he/she is not a resident of Italy. The purchase page will have IP address-based geolocation and will not be served to IP addresses located in Italy. We will not interrupt the service to current subscribers until the natural expiry date and the refund policy will be granted as usual.
 

REASONS FOR DISCONTINUATION

The so-called “Italian Piracy Shield” is a legal framework with implementing regulation by AGCOM (Italian Telecommunications Authority) that forces operators offering services in Italy to block access to end services through IP blocking and/or DNS poisoning.  The list of IP addresses and domain names to be blocked is drawn up by private bodies authorised by AGCOM (currently, for example, Sky and DAZN). These private bodies enter the blocking lists in a specific platform. The blocks must be enforced within 30 minutes of their first appearance by operators offering any service to residents of Italy.

There is no judicial review and no review by AGCOM. The block must be enforced inaudita altera parte and without the possibility of real time refusal, even in the case of manifest error. Any objection by the aggrieved party can only be made at a later stage, after the block has been imposed. For further details:
https://www-wired-it.translate.goog/article/piracy-shield-agcom-piattaforma-streaming-pirata-calcio-segnalazioni/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp

The above requirements are too burdensome for AirVPN, both economically and technically. They are also incompatible with AirVPN’s mission and would negatively impact service performance. They pave the way for widespread blockages in all areas of human activity and possible interference with fundamental rights (whether accidental or deliberate). Whereas in the past each individual blockade was carefully evaluated either by the judiciary or by the authorities, now any review is completely lost. The power of those private entities authorized to compile the block lists becomes enormous as the blocks are not verified by any third party and the authorized entities are not subject to any specific fine or statutory damage for errors or over-blocking.

By withdrawing service availability from Italy, AirVPN will be able to stay outside the scope of the framework and maintain integrity and efficient operations.

We certainly sympathise with our fellow Italian citizens, and we will be happy to offer advice and alternatives. We would also like to remind them of our more than ten years of support for the Tor network, which is freely accessible even from Italy, and which is becoming increasingly reliable and fast thanks to a myriad of small contributions like ours.

Kind regards and datalove
AirVPN Staff

AirPN

Insomma neanche nato e piracy shield de no artri già miete successi.

Del resto cosa può andare male a fronte ti tanta genialità, abbiamo pure una safelist per evitare problemi.

• certo uno potrebbe far notare che un IP può essere utilizzato da più di un servizio, e alcuni potrebbero essere assolutamente legittimi e quindi “bloccati” senza ragione

• uno potrebbe osservare che senza un monitoraggio attento il rischio di avere in blocklist ip importanti per un “errore” o per attività malevola non è nullo (immaginatevi di bloccare 8.8.8.8 o qualche nodo BGP importante)
• Uno potrebbe discutere sulla liceità di blocchi che non consentano una contestuale ed immediata opposizione

Ma perchè fermarsi di fronte a certe sciocchezze. La cosa certa che i successi arrivano e qui abbiamo la dimostrazione autoreferenziale indiscutibile ed indiscussa:

Che cosa significhi che hanno bloccato 65 DNS lo chiedo agli esperti 🙂

Per ulteriori indicazioni:

https://www.wired.it/article/piracy-shield-piattaforma-agcom-pezzotto-streaming-illegale/

https://www.wired.it/article/piracy-shield-agcom-piattaforma-streaming-pirata-calcio-segnalazioni/#due

Information security o Cyber security?

Istigato dal buon Alessandro Bottonelli, mio correo in #quellidelfascicolop mi è venuta voglia di puntualizzare un problema di nomenclatura che mi sta a cuore.

I termini Cyber ​​Security e Information Security sono spesso usati in modo intercambiabile. Entrambi sono responsabili della sicurezza e della protezione del sistema informatico da minacce e violazioni delle informazioni e spesso la sicurezza informatica e la sicurezza delle informazioni sono così strettamente collegate che possono sembrare sinonimi e, sfortunatamente, vengono utilizzate come sinonimi.

Se parliamo di sicurezza dei dati, si tratta di proteggere i dati da utenti malintenzionati e minacce. Ora qual è la differenza tra dati e informazioni?

Un punto importante è che “non tutti i dati possono essere informazioni” i dati possono essere informati se vengono interpretati in un contesto e gli viene dato un significato. Ad esempio “250865” è un dato e se sappiamo che è la data di nascita di una persona (la mia) allora è un’informazione perché ha un significato. Quindi informazione significa dati che hanno un significato.

Qual è la differenza tra la information security (sicurezza delle informazioni) e la cyber security (sicurezza informatica)?

La sicurezza delle informazioni e la sicurezza informatica sono campi correlati ma distinti che si concentrano sulla protezione di diversi aspetti dei sistemi informativi e tecnologici di un’organizzazione.

La sicurezza delle informazioni è un campo ampio che comprende tutti gli aspetti della protezione delle informazioni e dei sistemi informativi di un’organizzazione da accesso, uso, divulgazione, interruzione, modifica o distruzione non autorizzati.

I pilastri su cui si basa sono ovviamente:

• confidentiality
• integrity
• availability

cui occorrerebbe aggiungere

• non repudiation
• authenticity
• accountability

La sicurezza delle informazioni include la protezione delle informazioni sensibili, come i dati personali e le informazioni finanziarie, nonché i sistemi e i processi utilizzati per archiviare, trasmettere ed elaborare tali informazioni. All’interno della sicurezza delle informazioni ricadono quindi anche aspetti legati alla protezione del dato sia questo digitale che analogico.

Esempi e inclusione della sicurezza delle informazioni sono i seguenti:

• Controlli procedurali
• Controlli di accesso
• Controlli tecnici
• Controlli di conformità

La cyber security, d’altra parte, è largamente un sottoinsieme della sicurezza delle informazioni che si concentra specificamente sulla protezione dei sistemi tecnologici e dei dati di un’organizzazione da attori malintenzionati nel cyberspazio. Ciò include la protezione da attacchi di rete, violazioni dei dati e altri tipi di criminalità informatica. La sicurezza informatica include anche la protezione delle infrastrutture critiche, come centrali elettriche e sistemi finanziari, dagli attacchi informatici che espande il perimetro rispetto la Information security.

Esempi e inclusione della sicurezza informatica sono i seguenti:

• Sicurezza della rete
• Sicurezza delle applicazioni
• Sicurezza nel cloud
• Infrastrutture critiche

In sintesi, la sicurezza delle informazioni è un campo ampio che comprende tutti gli aspetti della protezione delle informazioni e dei sistemi informativi, mentre la cyber security si concentra specificamente sulla protezione contro le minacce e gli attacchi informatici. Entrambi sono importanti per garantire la sicurezza e l’integrità dei sistemi informatici e tecnologici di un’organizzazione.

vi torna?

ciao

The email files: se 40000 in blocklist vi sembran pochi

Vabbeh giusto un paio di giorni fa mi son trovato a discorrere di una richiesta di un SOC di mettere 40000 domini in una email-blocklist.

Ho cercato di spiegare che la cosa non ha senso, ma ho trovato una certa rigidità in merito.

Poi mi sono soffermato un attimo e mi son chiesto: io parlo di sicurezza, ma loro?

E mi son ricordato di quando cercavo di spiegare che mettere miliardi di regole su di un firewall dimostra solo di non aver capito come si configura un firewall per fare security 😂😁😎
Che faccio quindi? un update dell’articolo sotto per mettere alcuni punti in chiaro 🙂

The email Files: Blocklisting, la sottile arte di farsi del male da soli

https://thepuchiherald.com/the-email-files-blocklisting-la-sottile-arte-di-farsi-del-male-da-soli/

Blocklisting: un falso senso di sicurezza

Per qualche oscuro motivo una buona parte degli operatori di sicurezza informatica è convinta che gli attaccanti siano essenzialmente degli stupidi e che compiano azioni che riconoscerebbe anche un bambino.

Non riesco a spiegarmi in altro modo la propensione alle liste di blocco, sopratutto quando queste contengono decine di migliaia di entry.

Bloccare delle entry (tipicamente Indirizzi IP o domini) che sono già state individuate come malevoli è un po come chiudere le porte della stalla dopo che ne sono fuggiti gli animali.

Se pur vero che in minima parte certe entry, solitamente legate al perdurare di un attacco, possono essere attive, questo non è per sempre. Ma questo lo avevo spiegato in precedenza.

In compenso la gestione di liste gargantuesche comporta diversi problemi, sia prestazionali che di gestione vera e propria.

Che sia un email security gateway o un firewall tenere un approccio statico ai filtri raramente denota competenze specifiche nella sicurezza informatica.

Detto questo è sempre possibile che vi siano obblighi provenienti da sorgenti che non hanno nessun affinità con la materia, e quindi questo approccio diventa “necessario” alla sopravvivenza.

I motivi possono essere vari: “legali” o “politici” ma sicuramente non tecnici.

Ma proprio per questo difficilmente contestabili, mancando le basi minime di comprensione del fenomeno da parte di chi esegue la richiesta.

Quindi assumiamo che sia necessario, ancorché non sensato, dover implementare sui nostri sistemi statiche, stupide, chilometriche ed inutili liste di blocco. Dobbiamo in qualche maniera essere in grado di sopravvivere alla cosa.

Come sopravviverci?

Pur essendoci su internet diversi servizi di RBL mi soffermo qui sulla esigenza, prima espressa, di soddisfare una richiesta di implementare delle liste di blocco chilometriche all’interno del nostro servizio di sicurezza e non accedere a servizi pubblici di RBL.

Innanzi tutto è necessario ricordare che queste liste sono spesso un inutile accozzaglia di vecchie referenze che poco hanno a che fare col threat landscape corrente, occorre quindi NON affidarsi a queste ultime come unica sorgente di protezione.

In secondo luogo occorre prepararsi ad avere eventuali falsi positivi, nel malaugurato caso che domini legittimi utilizzati in attacchi finiscano in queste liste che probabilmente non sono sempre aggiornate.

In terzo luogo occorre che il security gateway che usiamo sia capace di processare queste liste anche in termini di consumo di risorse.

Il problema è presentato proprio dal fatto che spesso queste liste non sono legate a domini, IP o risorse web usate solo da criminali, ma anche da soggetti legittimi. In questo caso se le liste non sono aggiornate dinamicamente con una certa frequenza rischiamo di bloccare risorse lecitamente usate con le problematiche del caso.

La cosa è nota da anni, ed è il motivo alla base della diminuzione dell’uso delle RBL come strumento di filtro per meccanismo di analisi più efficienti (come ad esempio la reputazione dinamica delle risorse).

Le Real-time blackhole list (RBL) note anche come DNS Block List (DNSBL) sono generalmente liste pubbliche che raccolgono domini o IP che hanno una reputazione come emettitori di email illegittime (spam o peggio). Molti servizi su internet offrono questo tipo di liste ma, per mantenersi decentemente aggiornate, di solito non amano che un singolo utente richieda il blacklisting di un numero molto elevato di voci.

Bloccare un dominio tramite una risorsa pubblica potrebbe generare anche possibili conflitti legali, da qui la attenzione dei gestori di DNSBL alle entry e anche al delisting.

Ma cosa dobbiamo fare, quindi, se qualche illuminato della sicurezza ci chiede di caricare decine di migliaia di entry sui nostri sistemi?

La soluzione potrebbe essere legata alla creazione di una RBL interna.

Sebbene si possa implementare una RBL attraverso un normale DNS server per motivi di performance e di amministrazione è meglio orientarsi a software specifici.

RBL vs Filtri al gateway

La domanda potrebbe essere: perchè non implementare direttamente un filtro al gateway invece di usare risorse esterne?

Ci sono alcuni ottimi motivi per evitare l’approccio diretto al gateway di cui citerò solo 2 banali ed ovvi:

• Performance
• Amministrazione

Per quello che concerne le performance, difficilmente i security gateway moderni nascono per ospitare liste con diverse migliaia di voci. la ragione è che sono disegnati per fare sicurezza in maniera dinamica, e quindi servizi e risorse sono ottimizzati a quello scopo.

Dal punto di vista amministrativo, analogamente, a meno che non si disponga,come si diceva in precedenza, di un software specifico la gestione di queste liste è manuale e spesso complicata.

Utilizzare un software specifico per la gestione delle liste di blocco invece consente di aggirare i due problemi visti sopra demandando al security gateway la sola chiamata di controllo alla RBL.

Concludendo?

Pur rimanendo convinto che un approccio basato su interminabili block list sia fondamentalmente errato sotto qualsiasi punto di vista, se proprio non puoi fare a meno di implementare una stupidata di questo tipo cerca la via meno dolorosa:

1. Implementa una RBL o DNSBL interna con cui può parlare il tuo Gateway
2. Gestisci periodiche verifiche delle entry per evitare che vi possano essere problemi di falsi positivi e legali.

Vediamo se è l’ultima volta che scrivo di queste cose 😂😎🤣
#security #email

The email Files: Edizione Speciale- la email ai tempi della guerra.

Non è un bel momento in generale per il mondo, e questo numero degli “The email files” avrei preferito non doverlo scrivere.

Ma occorre essere concreti, e così ho deciso di scrivere un numero dedicato al minimo di igiene che occorre implementare per la mail in caso di guerra, o operazione militare speciale.

Non mi interessa da che parte state, le valutazioni qui espresse sono generali, la sicurezza informatica ha le sue ragioni che sono indipendenti da fedi, credi o appartenenze. Spero quindi che leggiate queste note per quello che sono, semplicemente alcuni consigli per gestire con maggiore sicurezza il media di comunicazione più diffuso ed usato.

Un minimo di contesto.

Mentre nei media mainstream per lungo tempo si è sollevata la leggenda dell’hacker solitario, con cappuccio, merendine, e schermo verde, il mondo reale è abbastanza diverso.

La realtà che muove la sicurezza informatica è molto più complessa, l’hacker solitario è una immagine romanzata e poco credibile. Questo, intendiamoci, non vuol dire che non possano esserci individui particolarmente dotati che lavorano in maniera solitaria, ma che la maggior parte del contesto in cui si muovono i rischi informatici è molto più legato a gruppi organizzati che a tali soggetti.

Soprattutto in termini di cybercrime e cyberwarfare la presenza di gruppi organizzati è una nozione consolidata tra chi si occupa di questi ambiti.

Le considerazioni che seguiranno fanno riferimento principalmente alla mail, ma per larga parte sono estendibili ad altri ambiti.

Il motivo di questa edizione speciale è, di per sé, evidente: siamo, al di là delle sottigliezze linguistiche, di fronte ad uno stato di guerra e questo comporta una escalation di alcune dinamiche che vanno considerate e gestite.

Rischiamo qualcosa?

Dovrei dire che le norme di sicurezza minime andrebbero implementate sempre, a prescindere dalle crisi geopolitiche. Ma sono cosciente che chi non si è mai preoccupato della sicurezza delle proprie informazioni e dei propri dati, che non capisce il valore sotteso agli asset digitali, che non ha idea di dove risieda ed in cosa consista la propria proprietà intellettuale possa trovare difficoltà a reagire di fronte all’alzarsi della paura di attacchi che, proprio in quanto non compresi, suonano ancora più spaventosi.

Allora cerchiamo di fare un poco di chiarezza:

La posta è ancora il primo vettore di comunicazione in campo entreprise, ed uno dei vettori più diffusi a livello personale. è anche uno degli obiettivi spesso usati per sviluppare attacchi sia in ambito aziendale che personale.

Le motivazioni sono diverse, ma al lato tecnico si sovrappone il lato umano. Le email sono lette da esseri umani e quindi la vulnerabilità umana è uno dei bersagli di attacco.

Se lo sfruttamento di tali vulnerabilità in campo criminale assolve a funzioni prettamente di guadagno economico, in tempo di guerra si aggiungono problematiche legate alla disinformazione, spionaggio e anche cyber-warfare.

In particolare va osservato come la commistione tra attività di cyber warfare e criminali portate avanti da alcuni attori possa spostare, a parità di tecnologia usata, obiettivi e quindi danni. Se un obiettivo economico, tipico del cybercrime, è legato all’acquisizione di soldi ma non alla distruzione della vittima (anzi meglio se si può tornare a batter cassa), uno di warfare può essere invece orientato all’annullamento delle capacità operative del bersaglio.

Tutto questo non è compatibile con la favoletta dell’Hacker, ma è compatibile con una realtà molto più complessa.

Anche limitandosi alle notizie apparse recentemente la cosa dovrebbe oramai essere entrata nella comprensione dei più. Qualcuno avrà sentito delle affermazioni del gruppo di cyber-criminali “conti” che ha dichiarato la sua adesione alle azioni russe, mentre il collettivo “anonymous” si è schierato a favore della resistenza in Ucraina.

Ora “conti” è una organizzazione che è dedita da anni ad attività di criminalità informatica (principalmente attacchi ransomware) di cui si sapeva ci fossero legami con l’intelligence Russa, ma fin ad ora non c’era stata una dichiarazione esplicita in tal senso da parte di “conti”.

“Anonymous” invece è un collettivo di “Hacktivisti” che ha avuto momenti di notorietà nei mainstream anche le attività solte in occidente. All’interno della galassia “Anonymous”, decentrata e non organizzata in termini assoluti, è nota da tempo anche la presenza di gruppi con legami al mondo occidentale, sia stati che organizzazioni “private”.

La realtà è che la commistione tra gruppi di hacktivism, spesso dediti al defacing, ddos e data exfiltration, cybercriminali, principalmente dediti ad attività di criminalità informatica tipo gli attacchi ransomware, e gruppi dediti al cyber warfare orientati spesso a spionaggio o danneggiamento delle infrastrutture (stuxnet ricorda qualcosa?) è nota da anni, non è certo una novità delle ultime 2 settimane. Addirittura per alcuni stati, come la corea del nord, tale commistione funge anche come meccanismo di approvvigionamento di valuta per finanziare strutture interne.

la situazione è quindi simile a quella descritta nell’immagine sottostante.

Insomma dalla narrazione del singolo hacker alla realtà corre una certa differenza. diciamo che una definizione delle attività correnti sarebbe più correttamente quella descritta sotto:

che rappresenta in maniera più fedele quello che accade negli ultimi anni.

La posta ai tempi della guerra.

Ma come ci aiutano queste informazioni nel gestire la posta?

Andiamo per gradi, cosi ci capiamo.

Il mondo descritto sopra è così da qualche anno, quindi, per quando sia difficile da credere, le cose da implementare non variano molto da una situazione di guerra ad una di pace per la posta. Quello che cambia, principalmente, è la esposizione al rischio che aumenta dal lato cyber warfare. questo significa che a fronte, come si era detto prima, di attacchi che usano tecnologie analoghe a quelle di tempo di pace, l’obiettivo potrebbe diventare non quello economico ma quello di fermare o distruggere le capacità operative della vittima.

Ovviamente non tutti hanno gli stessi rischi, ci sono obiettivi più esposti ed alcuni meno esposti. Ma considerando che le tecniche in uso sono analoghe a quelle normalmente usate alcune osservazioni vanno fatte.

Social Engineering

Dal phishing alla BEC c’è da aspettarsi che il numero di attacchi sia crescente, e che i temi relativi alla guerra, ai profughi, alle conseguenze economiche della crisi corrente, ed anche alle polemiche politiche sarà in rialzo.

Le aziende che hanno attività nei teatri di scontro potrebbero vedere anche un aumento della pressione di attacchi sulla supply chain.

Una differenza rispetto le operazioni normali, è che la commistione tra cybercrime e cyber-warfare potrebbe spingere l’attaccante a utilizzare la vittima come testa di ponte per effettuare l’attacco verso una terza parte.

Per quello che riguarda le infrastrutture critiche, ricordo che stiamo parlando ancora della posta elettronica, ci potrebbe essere invece lo sviluppo di un attacco lasciato quiescente. Questi target sono spesso obiettivo degli attori di cyber-warfare, il cui modus operandi è spesso esteso su tempistiche diverse rispetto alle attività di cybercrime.

Account Takeover

Essendo la posta un meccanismo che si basa, alla ricezione, principalmente sulla fiducia di riconoscimento del ricevente nei confronti del mittente, le attività di account takeover sono estremamente efficienti perché permettono di aumentare il livello di fiducia sui contenuti perché provenienti da una fonte “credibile”.

Ricevere un messaggio da un mittente noto è infatti un meccanismo molto facile per creare un vincolo di fiducia.

Malware ed altre schifezze

Ebbene sì, il malware continua ad arrivare e ad essere utilizzato. Niente di nuovo sotto il sole, ma il rischio di un aumento anche da questo punto di vista è realistico. Il malware può essere deliverato in diversi modi:

• tramite attachment
• tramite file associato ad una URL
• tramite codice malevolo su una landing page
• …

e via dicendo.

Occorre quindi avere un poco di attenzione.

Cosa fare?

In realtà siamo in un clima di Business As Usual con un livello di rischio più alto. Il che significa che le cose che si sarebbe dovuto fare in tempi normali, adesso diventa ancora più impellente implementarle in maniera corretta.

vediamo di dare qualche indicazione:

1. occorre avere un sistema di protezione della posta avanzato, che sia in grado di offrire analisi su social engineering (esempio phishing, BEC) , malware, e che offra capacità di sandboxing contro il malware
   1. antivirus aggiornato
   2. malware detection in modalità aggressiva
   3. Protezione su URL attiva sia in modalità preventiva ma anche e soprattutto “at click time” per contenuti compromessi post delivery
   4. meglio avere accesso a sistemi di Threat intelligence per monitorare, almeno, che tipo di threat actor sta attaccandovi.
2. approccio cautelativo sulla gestione dei file
   1. Non far passare gli eseguibili MAI
   2. fare scansione di tutto, limitare le eccezioni al minimo indispensabile
   3. nel dubbio metti in quarantena
   4. quello che non si può scansionare (file criptati, zip con password, file danneggiati) non va consegnato direttamente all’utente ma esploso in maniera protetta
3. Usate un approccio restrittivo sui protocolli di email authentication:
   1. Onorate le policy DMARC “reject” e “quarantine”
   2. Quarantenare gli SPF hard fail
   3. Quarantenare errori DKIM
4. Marcate le email provenienti dall’esterno in maniera che siano riconoscibili
   1. aggiungete una nota ad inizio email (nessuno legge fino alla fine) che evidenzi le email provenienti dall’esterno
   2. se non si possono creare note almeno cambiate il subject\oggetto
5. Verificate se serva una regola Anti-spoofing per bloccare almeno per i domini di cui siete sicuri non vengano generate email al di fuori dei vostri mailserver
6. Vietate lo scambio di posta per lavoro da parte di domini di email pubbliche (ex gmail, libero) a meno che non sia strettamente necessario
7. Verificate su canali di comunicazione alternativi (una telefonata vi salva la vita) tutte le richieste “inusuali” tipo cambio IBAN, solleciti pagamenti, comunicazione credenziali
8. Utilizzate sistemi di remediation automatica, nessun sistema è perfetto, non considerare la remediation vuol dire non ragionare in termini di sicurezza.
9. Formate gli utenti ed alzate il loro livello di attenzione.
10. Limitate al massimo le safelist, riducendole in numero e in termini di utenti cui le applicate. Se possibile non fate safelist che coinvolgono tutti gli utenti, leggetevi “the email files” sul safelisting

Insomma diciamocelo, non sono regole fuori dal mondo. A parte il riferimento alla threat intelligence il resto dovrebbe essere BAU (non nel senso del cane ma di Business as Usual).

Niente panico ma un minimo di norme di sopravvivenza, che in realtà funzionano anche in tempo di pace.

Buona serata

Antonio

The email Files: La posta secondo la posta

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:

1. dire a chi si manda la posta con un indirizzo del tipo nome@unarobadopo.xx
2. mettere un oggetto, insomma il titolo della email.
3. 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:

1. la posta è istantanea, come mando arriva
2. se leggo che il messaggio arriva da “pippo” deve essere “pippo” che la ha mandata
3. se c’è un allegato prima clicco e poi penso, che se “pippo” me lo manda un motivo ci sarà
4. 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:

1. quanto importanti sono i servizi di posta elettronica all’interno dei miei processi di business?
   1. uso la mail con i miei clienti?
   2. uso la mail con i miei fornitori?
   3. uso la mail per fini marketing?
   4. …
2. quale è la mia esposizione al rischio su questo canale?
3. quanti dati business critical sono contenuti nello store del mio mail server?
   1. quanta proprietà individuale è contenuta nel datastore del mail server?
   2. quante informazioni “critiche” per il business?
   3. …
4. come differenzio la gestione dei dati personali rispetto quelli aziendali contenuti nel mio mailserver?
5. 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 è

From: “=?UTF-8?B?UHJpbWEgQXNzaWN1cmF6aW9uaQ==?=” <support@offertemadeinitaly.it>

Come da aspettarci troviamo il campo TO: che in questo caso coincide con quello visibile su outlook.

To: antonio.ierano@ierano.it

interessante è notare che dopo il campo TO: troviamo il campo Reply-to:

Questo campo

Reply-To:

Serve a indicare in caso di risposta a chi deve essere mandata la risposta INDIPENDENTEMENTE da quanto contenuto nel campo FROM:

infine, abbiam il subject, l’oggetto.

Subject: =?UTF-8?B?UkMgYXV0byBhIHBhcnRpcmUgZGEg?=
 =?UTF-8?B?c29saSAxNDIgZXVyb3==?=

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)
• Dal Phishing alla sicurezza

meditate gente meditate

L'email security come tecnologia abilitante alla gestione del rischio

Accenture e Proofpoint ti invitano a partecipare al WEBINAR

L’email security come tecnologia abilitante alla gestione del rischio

Analisi delle esigenze tecnologiche, landscape e implementazione

25 febbraio dalle 10 alle 11.30 

Secondo il World Economic Forum, il 95% degli incidenti informatici è imputabili ad errori umani.

Il threat landscape corrente indica chiaramente come sia necessario indirizzare gli strumenti di sicurezza alla protezione degli individui. 

Per questo è indispensabile formare le persone e proteggere il primo vettore delle minacce, l’email.

Un’implementazione efficace richiede un supporto esperto che consenta di massimizzare i risultati dell’investimento.

Accenture e Proofpoint possono supportarvi fornendo la propria esperienza per creare un sistema sicuro.

REGISTRATI SUBITO

Dopo l’iscrizione, riceverai un’email di conferma con le informazioni necessarie per accedere al webinar.

AGENDA

• Cosa significa difendersi
• Proteggere il vettore numero 1 delle minacce
• Email Security Overview
• Security Awareness Training Overview

Antonio Ieranò – Evangelist-Cyber Security Strategy Proofpoint

• Real Use cases and implementation: Email Security Gateway

Stefano Pacchioni – Cyber Security Consultant Accenture Security

• Real Use cases and implementation: Security Awareness Training

Andrea Guerini – Security Associate Manager Accenture Security

• Conclusioni

Salvatore Torrisi – Managing Director Accenture Security

• Q&A

Ti aspettiamo!

Sicurezza ICT a Roma 16 Febbraio

Edizione particolare della mia newsletter aperiodica

Dopo quasi 2 anni finalmente riesco di nuovo a fare eventi non in remoto a Roma.

Se volete e se siete o passate a Roma magari ci si saluta di persona 😁.

📅 16 febbraio #SicurezzaICT22 🔒

a #Roma e in #livestreaming

Implementare sistemi di #security che non comunichino tra loro significa implementare silos che disperdono #dati e non consentono di inquadrare l’esposizione al #rischio.

Vieni a parlarne con Antonio Ieranò, Evangelist-Cyber Security Strategy di Proofpoint e gli altri ospiti dell’evento #phygital dedicato a #dataprotection, #privacy e #sicurezzaIT.

Scopri l’agenda completa della giornata ➡️ https://lnkd.in/dEzgPrJM

Ti aspettiamo in diretta!

#cybersecurity #intelligenzaartificiale #ransomware #business #compliance #cyberrisk #phygitalevent

Ciao

Meditate Gente Meditate

The email Files: Blocklisting, la sottile arte di farsi del male da soli

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.

alla prossima

Meditate gente meditate

Epiodio precedente:

The Email Files: Safelisting email? Poi non lamentarti

The email Files: Safelisting email? Poi non lamentarti!

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:

1. la maggior parte degli utilizzatori non sa cosa sia e come funzioni la posta elettronica
2. la maggior parte degli amministratori non sa cosa sia e come funzioni la posta elettronica
3. 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:

1. 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)
2. 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:

1. il filtro non blocca qualcosa che dovrebbe bloccare (ci si riferisce a questa evenienza come falso negativo)
2. 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?

Meditate gente Meditate