Alla luce del precedente articolo, ciò che stiamo cercando è un modello evolutivo rispetto al tradizionale modello di sicurezza perimetrale di cui abbiamo analizzato le principali criticità.
Prima di illustrare modelli alternativi, tuttavia, chiediamoci qual sia lo scenario peggiore in termini di Network Security: molti di noi potrebbero concordare sul fatto che abbia a che fare con il concetto di fiducia.
Zero Trust Security: cos’è, quali sono i principi cardine e i fondamenti applicativi
Indice degli argomenti
Zero trust Security: il giusto livello di fiducia
Comunemente, il livello di fiducia (“level of trust”) nel mondo delle reti informatiche definisce il limite inferiore della robustezza dei meccanismi di crittografia e sicurezza che saranno adottati dal progettista.
Una rete Zero Trust Security (ZTS) si basa proprio su questo concetto, ossia sull’assenza di fiducia nelle reti altrui e negli altri host. Interagiamo molto frequentemente con una rete del genere: Internet.
Internet ci ha insegnato alcuni preziosi concetti di cyber security: un diligente sysadmin, ad esempio, (oggi ancor più di ieri) proteggerà un server connesso a Internet in modo più approfondito da come proteggerebbe un analogo altro server in LAN. Ma perché? E se invece, con tutti gli investimenti che il CISO ha fatto nel corso del tempo in load balancers, UTM e firewall DPI, a seguito di un attacco ransomware si scoprisse (come nel caso Stuxnet) che la compromissione è inizialmente avvenuta da un ingresso lato LAN?
Nel caso specifico di Stuxnet, il lettore può reperire dozzine di documenti e ricerche su Internet che spiegano come la compromissione sia iniziata da una chiavetta USB malevola inserita da un tecnico di laboratorio compiacente.
Ragionare in termini di comunicazioni sicure
Il modello ZTS impone che tutti gli host vengano considerati come se fossero connessi a Internet. È come se le reti in cui gli host risiedono dovessero essere considerate ostili e compromesse. Solo con questo approccio si può iniziare a ragionare in termini di comunicazioni sicure, e l’automazione ci consente di estendere questo livello di sicurezza a tutti i sistemi dell’infrastruttura.
Le architetture di Rete modellate sullo standard ZTS non richiedono nuovi protocolli o librerie. Tuttavia, usano tecnologie già esistenti in modi nuovi.
Le interazioni tra il piano di controllo e il piano dati sono i punti più critici che richiedono automazione. Se le policy non possono essere aggiornate dinamicamente, le relative reti ZTS diverranno inattendibili, ergo, è fondamentale che questo processo diventi automatico e rapido.
Ci sono molti modi in cui questa automazione può essere realizzata. Uno di questi, ad esempio, è rappresentato dai sistemi di gestione delle configurazioni: un importante trampolino di lancio per una ZTS, poiché questi sistemi spesso mantengono gli inventari dei dispositivi e sono in grado di automatizzare l’applicazione delle configurazioni di rete nel piano dati.
In virtù del fatto che i moderni sistemi di gestione della configurazioni sono in grado sia di mantenere un inventario dei dispositivi che di automatizzare la configurazione del piano dati, sono uno dei primi tasselli per la realizzazione di un progetto ZTS.
Sicurezza perimetrale e Zero Trust Security: differenze
Il modello di sicurezza perimetrale tenta di costruire un muro tra risorse attendibili e non attendibili (ossia, tra reti locali e Internet). Viceversa, ZTS prende fortemente le distanze da questo modello e da questa scuola di pensiero, e ipotizza che gli attackers possano annidarsi dappertutto: piuttosto che costruire muri per proteggere gli elementi più critici dall’esterno, trasforma l’intero ecosistema architetturale in una milizia militarizzata.
Gli attuali approcci di sicurezza perimetrale assegnano un certo livello di fiducia alle reti da proteggere: tale approccio, appunto, viola il modello ZTS, poiché introduce delle policy lasche e comportamenti rischiosi a lungo termine, i sysadmin tendono infatti ad abbassare la guardia quando la rete viene considerata “affidabile”; ad esempio, raramente gli host che condividono la medesima subnet sono protetti anche dagli altri host in quella stessa security zone.
Nell’immaginario comune, la condivisione di una security zone, dopotutto, normalmente implica che gli host interni siano ugualmente affidabili… ma non è così, con buona pace di quanto indicato nel manuale utente del tal o tal altro UTM, e a discapito di quanto creduto fino a ieri da quel o quell’altro sysadmin abituato a ragionare esclusivamente in termini di “difesa perimetrale” e antivirus.
L’importanza di un’identificazione più efficace
Poiché la Zero Trust Security considera che la rete di un cliente possa essere parzialmente o già del tutto compromessa, dobbiamo valutare la possibilità che un attacker possa comunicare utilizzando indirizzi IP e porte a sua discrezione: ecco che, quindi, nello scenario delineato, notiamo come delle policies di cyber security che fondano il filtraggio esclusivamente su IP e porte (come normalmente avviene), non è sufficiente.
Tutti gli host, compresi quelli nelle security zones di più alto livello, devono appropriarsi di un’identificazione più efficace.
Gli attackers non si limitano allo sfruttamento degli attacchi popolari, ma ad esempio possono attuare anche attacchi stealth in modalità passivo-aggressiva in cui sniffano il nostro traffico di rete a caccia di dati sensibili (o bancari): in questi casi, la sola identificazione non è sufficiente, occorre anche una buona crittografia dei dati trasportati.
Componenti essenziali nelle architetture Zero Trust Security
Tre sono i componenti essenziali nelle architetture Zero Trust Security:
- user/application authentication;
- device authentication;
- livello di trust.
Il primo componente ingloba due aspetti proprio perché non tutte le azioni sono intraprese dagli utenti: ad esempio, nel caso negli scenari di automazione (all’interno di un datacenter ad esempio, o di un impianto industriale) dovremmo osservare e monitorare il traffico di rete e le autenticazioni dei processi applicativi analogamente a come lo facciamo per gli account degli utenti.
Le autenticazioni e le autorizzazioni dei device (features presenti raramente nei sistemi perimetrali SOHO), invece, sono servizi fondamentali, ma a valle dell’autenticazione delle applicazione e/o degli utenti (generalmente i sysadmin li rendono disponibili sfruttando tecnologia NAC, ma trovare meccanismi di AAA sugli endpoint, è assai meno comune).
Infine, viene calcolato un “trust score” e l’applicazione, il dispositivo e il punteggio sono utilizzati per effettuare la configurazione di un agent. La policy viene quindi applicata nei confronti dell’agent al fine di autorizzarne la richiesta.
La ricchezza di informazioni contenute all’interno dell’agent consente una flessibilità accurata nel controllo degli accessi, flessibilità che potrà adattarsi a condizioni variabili, granulari e dinamiche, includendo il “punteggio di affidabilità” nelle nostre policy ZTS.
Se la richiesta verrà autorizzata, il piano di controllo segnalerà al piano dati di accettare la richiesta in arrivo. Questa azione potrà coinvolgere anche i dettagli del livello di crittografia, che potrà essere applicata a device, ad applicazioni o su entrambi (ne serve almeno uno per garantire Riservatezza).
Con questi componenti e l’aiuto del piano di controllo nel coordinare i canali cifrati, possiamo affermare che ogni singolo flusso sulla rete sarà pianificato e autenticato.
Inoltre, registrando ciascuno degli eventi e delle azioni del piano di controllo, il traffico di rete potrà essere facilmente verificato in base ai flussi e alle richieste. Ci si può imbattere in sistemi di sicurezza perimetrale che hanno capacità simili, sebbene queste attività sono applicate esclusivamente al perimetro.
Le VPN tentano notoriamente di fornire queste proprietà per garantire l’accesso a una rete interna, ma la sicurezza termina non appena il traffico raggiunge il relativo concentratore VPN. È evidente che i progettisti sanno come dovrebbe essere implementata la sicurezza di Internet e delle Reti, ma semplicemente non riescono a implementare tali misure su tutti i layer.
Le VPN diventano obsolete
Se si riesce a immaginare una Rete che applichi queste misure in modo omogeneo, ideare qualche semplice progetto può gettare molta luce su questo nuovo paradigma. L’identità può essere provata anche crittograficamente, il che significa che non importa più di tanto da quale indirizzo IP una certa connessione avrà origine.
Con l’automazione che ridefinisce le barriere tecniche, le VPN essenzialmente diventano obsolete: le reti “private” non significano più niente di speciale, poiché gli host in una ZTS saranno hardenizzati così come quelli esposti su Internet.
A tal proposito, sono molte le sfide aperte nell’implementazione e nella migrazione di un’infrastruttura informatica in cloud, e una delle più grandi riguarda la cyber security. A tal fine, il modello ZTS costituisce una sorta di assicurazione tecnologica per un’ovvietà di motivi, ma soprattutto per uno in particolare: perché non possiamo fidarci ingenuamente della Rete e dei data center di un cloud pubblico.
Poiché ZTS prevede che ogni pacchetto sia cifrato, anche all’interno degli stessi data center, i sysadmin non dovranno preoccuparsi di quali pacchetti attraverseranno Internet, e quali no. Questo vantaggio è spesso sottovalutato.
Il carico cognitivo associato ad analisi di questo tipo – ossia a come dove ed eventualmente se cifrare il traffico di rete – può essere pesante, in particolare per i team di sviluppatori che potrebbero non conoscere né comprendere pienamente il sistema sottostante.
Eliminando i casi speciali, possiamo verosimilmente ridurre anche l’errore umano ad essi associato. Alcuni potrebbero obiettare che la crittografia all’interno del proprio datacenter, seppur in cloud, sia eccessiva, tuttavia la storia e l’evoluzione dei sistemi ci dimostrano il contrario. Presso i grandi cloud provider come AWS, ad esempio, un’unica regione è costituita da molti datacenter, con collegamenti in fibra tra di loro. Questa sottigliezza è spesso trascurata dal cliente finale. L’NSA stava prendendo di mira precisamente collegamenti come questi nel 2013, e ancor prima collegamenti alla dorsale Internet grazie a stanze come quella mostrata nella figura sottostante.
Fonte.
Conclusioni
Ci sono inoltre rischi nell’implementazione della rete dello stesso cloud provider (riprenderò comunque la tematica del modello ZTS applicato alle infrastrutture in cloud in successivi articoli) e non è così eccessivo ipotizzare che possano esistere vulnerabilità in cui gli utenti degli altri tenant in cloud possano accedere o addirittura modificare la nostra infrastruttura.
Risulta invece del tutto frequente che gli operatori del cloud provider ispezionino il traffico di rete durante un troubleshooting: probabilmente il sistemista che sta effettuando l’attività è assolutamente in buona fede, ma possiamo dire lo stesso del tizio che magari gli ruberà il laptop aziendale mentre sta tornando a casa in metropolitana? (laptop su cui quel sistemista aveva salvato le credenziali per accedere al nostro Windows Server, o a qualunque altro sistema aziendale che stava analizzando; laptop che non era agganciato ad alcun sistema di virtualizzazione lato server, da cui sarebbe stato possibile disattivare tempestivamente l’accesso agli account dei clienti; laptop che magari non ha neanche l’hard disk cifrato né un’autenticazione all’avvio con un token hardware, di cui quel sistemista è stato sempre sprovvisto).
La cruda realtà è che in un’architettura di rete tradizionale non possiamo asserire con certezza che il nostro traffico di rete sia protetto da ficcanaso, da sniffer o da modifiche anche nel più promettente dei datacenter.
Abbiamo introdotto i concetti ad alto livello che ci hanno traghettato verso la ZTS. Il modello ZTS supera il modello di sicurezza perimetrale, che tentava di garantire che gli attackers dovessero rimanere segregati dalla rete interna “affidabile”.
Invece, la ZTS nasce proprio con il presupposto che i cyber threats siano già presenti anche nella Rete interna, ed accumula meccanismi di Sicurezza e sistemi di monitoraggio basati sulla Crittografia per difendersi da questi scenari.
