La modellazione di una rete Zero Trust Security (ZTS), come abbiamo visto in un precedente articolo, implica un vero e proprio cambio di paradigma. Sfruttando l’applicazione delle policy distribuite e applicando i principi della modellizzazione ZTS è infatti possibile arrivare a produrre un’architettura simile a quella indicata nell’illustrazione sottostante.
Analizzandola, notiamo che è presente un piano di controllo (Control Plane), mentre quasi tutto il resto è indicato come piano dati (Data Plane), che viene coordinato e controllato dal piano di controllo.
Le richieste di accesso alle risorse protette vengono prima vagliate dal piano di controllo, dove sia il dispositivo che l’utente devono essere autenticati e autorizzati. È possibile applicare criteri dettagliati su questo livello, magari in base al ruolo nell’organizzazione, all’ora, al giorno o al tipo di dispositivo.
L’accesso a risorse più sicure può inoltre richiedere un’autenticazione più forte; una volta che il piano di controllo ha decretato che la richiesta è da autorizzare, configurerà dinamicamente il piano dati per accettare il traffico da quel client (e solo da quel client). Inoltre, può coordinare i dettagli di un tunnel cifrato tra il client e la risorsa. Ciò può includere credenziali, chiavi e numeri di porta temporanei monouso.
Sebbene possano palesarsi compromissioni anche sulla base di queste misure, l’idea alla base di questa tecnica è che una fonte autorevole, o una terza parte fidata, abbia la possibilità di autenticare, autorizzare e coordinare l’accesso in tempo reale, sulla base di una varietà di parametri.
Indice degli argomenti
Evoluzioni del modello di sicurezza perimetrale
L’architettura tradizionale a cui la maggior parte degli architetti e operatori ICT sono abituati (sia in aziende che in Enti Pubblici, e perfino negli insegnamenti di molte Università) è derivata dal modello di sicurezza perimetrale, che richiama l’approccio del muro fortificato utilizzato negli ambiti della Sicurezza fisica.
Questo modello protegge gli oggetti più interni costruendo linee di difesa progressive che un attacker deve penetrare sequenzialmente prima di ottenere l’accesso. Sfortunatamente, i data leak e i data breach degli ultimi anni (ransomware ma non solo) ci dimostrano come questo approccio si sia rivelato fallimentare nel mondo delle reti informatiche, e non è più perseguibile.
Come illustrato nella figura seguente, un attacco efficace alla sicurezza perimetrale coinvolge diversi passi:
- in primo luogo, l’attacker proverà a compromettere un host della rete interna sfruttando una vulnerabilità nel browser di un utente target, piuttosto che inviando direttamente agli account di posta aziendali un’e-mail con un allegato contenente un exploit. L’exploit trasporta un piccolo payload: del codice appena sufficiente per stabilire una connessione a un host su Internet, ma in grado poi di eseguire del codice che riceve in risposta dall’host controllato dall’attacker;
- l’utente avvia inconsapevolmente l’exploit sul proprio host;
- tramite lo sfruttamento dell’exploit, l’attacker riuscirà ad installare un vero e proprio malware sulla postazione della vittima;
- tramite il traffico di rete verso il/i server C&C (Command & Control), l’attacker piloterà da remoto il malware che ha installato sull’host della vittima, riuscendo a fare esfiltrazione di dati, piuttosto che connessioni interattive (ma silenti agli occhi dell’utente) all’host.
Figura 1: fasi di un tipico attacco a un host (s)protetto da firewall perimetrale.
Questo “paziente zero” funge essenzialmente da trampolino di lancio, fornendo all’attacker un host in LAN (o WLAN) dal quale pianificare e lanciare ulteriori attacchi.
Forse il lettore meno attento non avrà notato un particolare nel primo step illustrato nella Figura 1: perché la prima freccia verso destra, dall’alto, è possibile? Perché effettivamente l’utente riesce a contattare il sito infetto (predisposto ad-hoc) dall’attacker? Ci riesce poiché nella maggior parte delle architetture di Rete presenti oggi nelle aziende, non vengono imposte policy per il traffico in uscita, ma essenzialmente solo in entrata: se si è fortunati (ma la fortuna, come nella matematica, nel mondo della cyber security è un elemento di un’equazione su cui non è opportuno fare affidamento), o meglio, appunto, se sono stati previdenti, gli architetti di rete avranno imposto anche dei filtri al traffico in uscita… se sono stati invece molto attenti, avranno predisposto in uscita anche degli appositi filtri (e allarmi) oltre che sul traffico web, anche sui più classici protocolli DNS e ICMP (sulle cui opportunità e minacce ci soffermeremo nelle prossime puntate). Questo non vuol dire necessariamente segregare militarmente una rete… ma ragionare in termini, appunto, di chi può collegarsi a cosa (e verosimilmente quando e da quale/i postazione/i).
I rischi di un attacco agli host in una LAN
La possibilità di perpetrare attacchi agli host in una LAN – sebbene “apparentemente” protetti da un sistema di sicurezza perimetrale – costituisce una minaccia decisamente preoccupante. Questi host hanno il permesso di comunicare con altri host nella stessa subnet, nonché nella stessa zona di sicurezza, e potrebbero anche avere la possibilità di interagire con gli host (e quindi potenzialmente di compromettere) operativi in Zone di Sicurezza (o “Network Security Zones” se volessimo utilizzare il relativo anglicismo) più sicure della propria.
A tal fine, compromettendo prima una zona a bassa sicurezza della rete interna, un attacker potrà verosimilmente spostarsi lateralmente (lateral movement) nella rete bersaglio, eventualmente guadagnando accesso alle zone a maggior sicurezza (o “High-Security Zones”).
Il difetto architetturale (presentato nella Figura 1) consente l’avanzata dell’attacker in maniera sottile ma efficace: le policy di sicurezza sono definite dalle Zone, applicate solo ai confini della zona in esame (o “Networks Boundaries”), utilizzando null’altro che i dettagli di origine e destinazione.
Anche se il modello di sicurezza perimetrale è ancora il modello più diffuso, è sempre più palese l’ingenuità di aziende ed enti – pubblici e privati – che si affidano a quello che è, in sostanza, un modello assolutamente ingannevole: ripeto, basta leggere ogni giorno (o potremmo dire ogni ora se considerassimo nel suo complesso anche la stampa estera?) gli attacchi informatici andati a segno contro reti e infrastrutture cibernetiche apparentemente protette da soluzioni di sicurezza perimetrale.
Un attacker (che non necessariamente dev’essere un esterno) installa uno dei tanti tool per l’accesso remoto (mi riferisco ai software R.A.T., che non necessariamente vengono etichettati come malevoli dagli antimalware: si pensi, ad esempio, allo stesso TightVNC, di cui è possibile eseguire un setup silente su di una workstation o su di un server) nella LAN target tramite uno qualunque dei metodi ad oggi conosciuti, ottiene l’accesso remoto e inizia a muoversi lateralmente.
Ecco, quindi, che un dispositivo che promette(va) di tenere fuori dalle “mura aziendali” nemici e spioni, sfruttando un altro punto di vista (ossia quello dell’attacker) e di appoggio, può diventare null’altro che un inutile pezzo di ferro tra gli attacker e la LAN che promette(va) di proteggere.
L’anomalia del modello di sicurezza perimetrale
L’anomalia fondamentale alla base del modello di sicurezza perimetrale si presenta quando si definiscono le zone di sicurezza nella stessa rete.
Immaginiamo il seguente scenario: gestisci una piccola azienda il cui core business è l’e-commerce. Tale azienda ha qualche impiegato, alcuni sistemi interni (economato, inventario, magazzino, back-office ecc.), alcuni server per alimentare il tuo portale on-line, e si avvale anche di alcuni consulenti esterni.
È prassi comune iniziare a classificare il tipo di accesso di cui potrebbero aver necessità questi gruppi: i dipendenti avranno indubbiamente bisogno di accessi ai sistemi interni, i server web dell’accesso ai database, i database server non hanno bisogno dell’accesso a Internet se sfruttano un middleware, ma i dipendenti sì e così via.
Il modello di sicurezza perimetrale tradizionale codifica questi gruppi in zone, quindi definisce quale zona potrà accedere a cosa, come mostrato nella seguente figura.
Figura 2: tipica rete corporate che interagisce con la rete di produzione.
Occorre far rispettare in maniera certosina le relative policy, e poiché sono definite zona-per-zona, è doveroso applicarle ovunque una zona possa indirizzare del traffico verso un’altra.
Zero Trust Security: dalla teoria alla pratica
Bene, finora probabilmente siamo verosimilmente tutti d’accordo ma, come possiamo immaginare, la realtà (anche quella italiana) è spesso diversa dalla bella teoria “pulita” che si studia nella aule universitarie.
Giacché, ad esempio, possono sorgere delle eccezioni (in realtà sfido qualunque lettore a dimostrarmi che nel proprio firewall – mi riferisco ovviamente ad apparati che gestiscono il traffico di rete di almeno 80-100 utenti – non siano state configurate delle eccezioni per una zona o per un importante cliente o manager di passaggio in azienda: eccezioni poi magari dimenticate negli anni, e ancora adesso annegate nei meandri della CLI dell’appliance) alle policy, eccezioni conosciute dai tecnici come appunto firewall policy exceptions.
In genere, queste eccezioni dovrebbero essere (il condizionale che sto adottando non è un caso) le più ristrette possibili, ad esempio: lo sviluppatore web potrebbe dover accedere in SSH ai server Web in produzione e dovrebbe farlo solo e soltanto da una certa macchina Linux avente un certo IP statico, oppure il responsabile HR potrebbe dover accedere ai database server delle risorse umane per eseguire degli audit.
In questi casi, un approccio diffuso consiste nel configurare un’eccezione nel firewall che generalmente nega il traffico di rete dall’indirizzo IP di quell’individuo al particolare server in questione, ma che invece appunto grazie all’eccezione inserita, autorizzerà quello specifico traffico.
Bene, tutto funziona: il business va avanti con le eccezioni configurate dal sistemista network. Ora, tuttavia, immaginiamo che un tuo competitor si sia rivolto per una consulenza operativa – ovviamente a tua insaputa – a un team di blackhats.
Il loro obiettivo è dare un’occhiatina al tuo inventario, ai tuoi progetti, ai riferimenti di tutti i tuoi clienti, e magari anche alle tue carte di credito.
Il team di blackhats prende molto seriamente il tuo competitor e il suo obiettivo, e inizia inviando un’email a tutti gli account di posta dei tuoi dipendenti e consulenti (che potrebbero reperire non solo sul tuo portale web, ma anche su LinkedIn ad esempio, o su dei social networks a tua totale insaputa), un’email un po’ particolare, come se provenisse da un ristorante di recente apertura – così si presenta l’accattivante email – nei pressi del quartiere dove hanno sede gli uffici della tua azienda, e contenente un codice sconto del 50% per un pranzo a base di sushi, ma valido solo se sfruttato entro una settimana dall’invio via email e se si è ancora clienti.
Verosimilmente allettato dalla proposta, uno dei tuoi dipendenti fa click su di un ghiotto collegamento presente nell’email (quando lo fa, siamo vicini all’ora di pranzo…), e per giunta scarica e disgraziatamente avvia un innocuo file apparentemente in formato .pdf contenente il menu (che un’eventuale analisi forense, mesi dopo, mostrerebbe non essere esattamente un normalissimo file .pdf) consentendo – inconsapevolmente – ai blackhats di installare un malware sulla postazione del tuo dipendente.
Il malware bypassa il firewall perimetrale e si collega in VPN ad un server virtualizzato che i blackhats hanno messo in piedi a Panama (noto Paese famoso per avere ferree leggi sul tracciamento degli accessi dei sysadmin), consentendo poi agli attackers di collegarsi alla postazione dell’ignaro utente. Sei fortunato: è solo uno stagista, e il livello di accesso che ottengono è limitato. Ma non si scoraggiano e iniziano a studiare le sottoreti a cui ha accesso il tuo dipendente (che nel frattempo è all’oscuro di tutto: ha solo notato un leggero rallentamento nei tempi di risposta del suo browser e dell’Esplora Risorse di Windows… ma nulla più… e del resto, non è abituato a porsi più di tanto domande sistemistiche), e scoprono che l’azienda condivide files e folder in LAN sfruttando il protocollo SMB, e se ne accorgono proprio incappando in una share Windows Server (a cui non è stato associato nessun sistema di Log Management).
Da una successiva scansione con strumenti disponibili gratuitamente nella distribuzione Kali Linux, i blackhats si accorgono che dei computer e server nella tua LAN nessuno monta le ultime patch di sicurezza, e sono vulnerabili a un micidiale exploit che è stato pubblicato neanche tanto di recente.
I blackhats iniziano a cercare un sistema con accesso elevato, e alla fine si imbattono nella workstation del tuo sviluppatore web. Ci installano sopra un keylogger per recuperare le credenziali dell’accesso al web server. Si collegano quindi in SSH al server utilizzando l’account del tuo sviluppatore, e poiché nessuno ti ha mai proposto né messo in piedi alcun IDS, nessuno continua ad accorgersi di niente: i blackhats sfruttano quindi i diritti “sudo” dello sviluppatore, leggono dal codice sorgente di un applicativo aziendale (che scovano all’interno del server Git) le credenziali per accedere ai database (giacché lo sviluppatore web non ha rispettato le best practice di Secure Coding, che tra le altre cose prevedono appunto di non annegare in chiaro nel codice sorgente le credenziali per connettersi ai sistemi di back-end) e ci si collegano. Effettuano il dump di gigabyte di interessanti dati dal tuo database, e al termine eliminano il relativo file di log degli accessi, coprendo quindi le proprie tracce dell’accesso abusivo.
Dulcis in fundo, installano dei rootkit nei firmware dei tuoi due firewall obsoleti (giacché hanno notato che anche i tuoi firewall sono vulnerabili, sebbene manipolabili con un altro exploit), così, eventualmente da ritornare nella tua LAN con comodità per una futura visitina (nella remota ipotesi che qualcuno si accorgesse dell’avvenuto accesso abusivo, e provvedesse alla bonifica di pc e server in LAN) o per vendere quei medesimi accessi nel Dark Web al miglior offerente. Missione compiuta, il cybercrime è andato a segno: il tuo competitor ha raggiunto il suo obiettivo.
Sono stati molti i deficit che hanno portato a questa violazione: ma mentre potreste pensare che quello illustrato sia un caso particolare, attacchi di successo proprio come questo sono all’ordine del giorno.
La parte più sorprendente però passa inosservata, troppo spesso: che fine ha fatto la sicurezza perimetrale? I firewall sono stati collocati meticolosamente, le policy e le eccezioni erano restrittive e limitanti, tutto sembrava ben fatto dal punto di vista del modello di sicurezza perimetrale. Quindi, com’è potuto accadere?
Conclusione
Se esaminiamo meglio l’architettura, risulterà palese anche al lettore che per fornire Network Security questo modello non basta, non è esaustivo.
Bypassare la sicurezza perimetrale è banale quanto far avviare un malware che si connette dall’interno dell’azienda verso Internet, con i firewall tra le zone che non considerano altro che sorgenti e destinazioni quando si tratta di autorizzare o droppare del traffico di rete.
Mentre la definizione dei perimetri e la loro gestione possono ancora fornire un certo valore alla Network Security, il loro ruolo come meccanismo di protezione essenziale (e in quante aziende italiane è ancor oggi così?) dev’essere ridefinito, e anche velocemente.
