Informazioni personali

Cerca nel blog

Translate

venerdì 10 settembre 2021

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?

Antonio "Puchi" Ieranò
Meditate gente Meditate

Nessun commento:

Posta un commento