Si parla tanto di Zero Trust Architecture (ZTA), ma pare che il concetto di Assume Breach Design non sia ancora stato formalizzato. O, almeno, una ricerca su Google non mi da risultato. Si parla di Assume Breach Paradigm, e io lo voglio applicare al design delle infrastrutture. Voglio quindi appropriarmi (si fa per dire) del termine e spiegare perché potrebbe essere utile cambiare mentalità.

Come sempre l’idea nasce sul campo, quando mi rendo conto che il design delle infrastrutture, dal punto di vista della Cybersecurity, segue un approccio classico. Negli anni 90-00 si era soliti implementare una rete DMZ, una rete server, eventualmente una rete client e le policy erano disegnate sulla base di necessità applicative e mai formalizzate. Questo approccio usato molto frequentemente anche oggi, si basa sull’architettura 3-tier delle applicazioni web: client, server e database dovevano essere implementati separatamente. Lato security la conseguenza è stata quella di separare logicamente questi componenti mediante un firewall.

Quello che vedo oggi è esattamente la conseguenza di questo: i sistemi vengono separati in base ad una logica applicativa, non di security. Il risultato è che le aziende hanno zone di sicurezza che separano componenti applicativi (Internet, DMZ, client, server, OT, Guest) e le policy derivano da esigenze applicative, non si security.

Un esempio su tutti: le reti server contengono tipicamente backend e database di tutta l’azienda. Se uno viene compromesso, l’intera rete è a rischio.

Un secondo esempio altrettanto esplicativo: immagino chiunque abbia implementato policy sul firewall in base ad una richiesta applicativa. La stragrande maggioranza delle policy su un firewall ha la stessa origine: sono necessità applicative e raramente ne viene valutato l’impatto perché non è possibile rifiutare la richiesta.

Policy design

Il primo tentantivo di cambio di mentalità l’ho fatto quasi dieci anni fa. Ero nella condizione di poter influenzare l’architettura di rete e sicurezza dell’azienda per cui lavoravo, e su spunto di un auditor ISO27001 ho formalizzato le interazioni tra zone di sicurezza diverse.

L’idea era di pubblicare un manifesto in modo che chiunque in azienda conoscesse le regole che governavano i firewall.

Vediamo qualche esempio:

• la rete server non può ricevere connessioni da Internet;
• la rete DMZ può accedere alla rete server solo su protocolli HTTP/HTTPS;
• le reti server e DMZ potevano accedere ad Internet solo su uno specifico elenco di indirizzi/protocolli.

Tutte le regole erano costruite per ridurre il rischio di compromissione o di lateral movement. Ma c’erano alcuni errori di fondo.

Il primo errore (mio) era che la valutazione era stata fatta da me che, all’epoca, avevo una esperienza che derivava prettamente dalla sicurezza difensiva. Qualche anno dopo, quando ho cominciato ad occuparmi anche di sicurezza offensiva, mi sono reso conto che l’approccio era corretto ma le ipotesi erano incomplete.

Il secondo errore (aziendale) è stato di non dare dignità a questo lavoro che era visto come un ostacolo da tecnico paranoico piuttosto che un documento per disegnare in sicurezza le applicazioni all’interno dell’azienda.

In particolare il paradigma 3-tier è stato convertito in Client (Internet) - Reverse Proxy (DMZ) - Server. Va da se che un reverse proxy, senza alcuna funzionalità se non quella di riportare le connessioni ricevute da Internet sulla rete interna, ha l’unica conseguenza di esporre la rete interna direttamente su Internet. Questo fatto dovrebbe apparire ovvio, ma ancora oggi trovo diverse configurazioni di questo tipo.

L’ultima conseguenza è che quando ho lasciato quell’azienda, il manifesto è stato messo da parte e dimenticato.

Una cosa da tecnici

Ad ogni modo l’esperienza fatta mi ha aiutato negli anni a fornire un approccio ai team tecnici che dovevano mettere ordine nelle policy firewall. Spostare l’attenzione dalla policy alle necessità dei sistemi prima di decidere dove piazzarli, aiuta a prevenire i problemi invece di rincorrerli.

La formalizzazione delle policy non ha mai funzionato, perchè è era visto dalle aziende come una cosa da tecnici e non legata al business.

In particolare le parole che un CEO mi ha detto alcuni anni fa sono state illuminanti: la Cybersecurity è un problema tecnico ed è pertanto affidata al CIO.

Il senso della DMZ

C’è un ulteriore fatto che mi ha spinto a ripensare l’approccio per difendere le aziende. Mi capita spesso di analizzare le policy dei firewall per cercare di dare una logica e mettere ordine. Quasi sempre trovo regole di NAT che permettono l’accesso di sistemi interni direttamente da Internet. Molto spesso sono necessità che riguardano particolari applicativi, sistemi IoT, videocamere, o building automation in genere.

In tutti i casi esiste una DMZ il che mi da lo spunto per chiedere quale sia il senso di avere una DMZ e poi avere sistemi interni esposti direttamente.

Quello che ho scoperto è che la DMZ viene spesso creata senza avere un’idea chiara del concetto che ci sta dietro.

Originariamente la rete DMZ era pensata per essere il segmento più a rischio dell’infrastruttura: le policy che governavano il traffico da e verso la DMZ dovevano essere particolarmente stringenti. Qualcuno oggi citerebbe l’approccio Zero Trust.

Tornando indietro di parecchi anni, i sistemi in rete DMZ non avevano accesso a Internet. Questa scelta era motivata dal fatto che se un sistema veniva compromesso, da li non era possibile uscire.

Negli anni questo paradigma è caduto (come molti altri) perchè molti framework applicativi hanno la necessità di richiedere risorse esterne (schema XML, telemetria, licenze).

Il concetto di “contenimento” della DMZ è via via caduto e oggi una rete DMZ rischia di essere una rete come le altre. Piuttosto frequentemente mi capita di trovare:

• database che risiedono nella rete DMZ;
• reti DMZ che possono accedere in modo indiscriminato alle reti internet;
• sistemi interni che possono accedere in modo indiscriminato alla DMZ;
• accesso Internet senza limiti dalla DMZ e dalle reti interne;
• sistemi più o meno deboli esposti su Internet che risiedono in DMZ ma anche in reti interne;
• reverse proxy che mappano sistemi interni su Internet senza offrire alcun meccanismo di sicurezza.

Potrei continuare, ma credo di aver dato l’idea.

Defense in depth

L’idea alla base del paradigma defense in depth è quella di difendere un sistema da attacchi cyber usando un approccio multi-layer. In altre parole non dobbiamo limitarci ad usare una singola protezione (il firewall), ma dobbiamo prevedere layer multipli che possano agire assieme se uno o più protezioni falliscono.

Per capirci, un layer di difesa può essere costituito da:

• firewall
• VPN
• antimalware
• MFA
• monitoraggio
• vulnerability scanner
• IDS / IPS
• sicurezza fisica

Defense in depth è promosso da NSA che invita ad associare a ciascun layer una o più delle 5 funzioni cybersecurity così come definite nel cybersecurity framework formalizzato dal NIST .

Trovo l’approccio Defense In Depth assolutamente corretto, ma, a mio parere, rischia di essere tecnico e quindi slegato dal business. In un certo senso è l’errore che ho commesso io: non riuscendo a parlare al business non sono riuscito ad avere lo spazio che mi serviva.

Zero Trust Architecture

ZTA sta, purtroppo, diventato un mantra. ZTA è definito dal NIST nel documento SP 800-207 che dovrebbe essere studiato prima di parlare di ZTA. Provo a riassumere alcuni dei punti che mi sono utili nelle mie riflessioni, citando direttamente il documento originale.

That is, authorized and approved subjects (combination of user, application (or service), and device) can access the data to the exclusion of all other subjects (i.e., attackers). To take this one step further, the word “resource” can be substituted for “data” so that ZT and ZTA are about resource access (e.g., printers, compute resources, Internet of Things IoT actuators) and not just data access.

ZTA riguarda l’accesso ai dati, dove il dato può risiedere su qualsiasi sistema, incluse stampanti, sistemi IoT, e ovviamente server, database e via dicendo. L’oggetto è quindi il dato digitale in qualsiasi forma esso sia.

Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes.

L’accesso al dato è determinato da policy dinamiche costruite in base a chi chiede il dato, chi detiene il dato. Le policy possono tenere conto di altri attributi ambientali o comportamentali.

Requesting asset state can include device characteristics such as software versions installed, network location, time/date of request, previously observed behavior, and installed credentials. Behavioral attributes include, but not limited to, automated subject analytics, device analytics, and measured deviations from observed usage patterns.

Oggi costruiamo le policy basandoci sull’identità di sorgente e destinazione. L’identità della destinazione è tipicamente costituita da indirizzo IP e porta. L’identità della sorgente è leggermente più complessa e tiene conto non solo dell’indirizzo IP ma anche dell’utente associato. Nelle infrastrutture più complesse la sorgente viene anche validata secondo alcuni requisiti che riguardano lo stato di patching e la presenza di antimalware.

Raramente facciamo uso di attributi relativi a luogo e tempo. Ancora più raramente facciamo uso di attributi comportamentali (ad esempio se il client ha comportamenti diversi da quanto previsti).

L’approccio ZTA richiederebbe di permettere l’accesso al dato solo se strettamente necessario. Per fare questo dovremmo:

• identificare la sorgente in termini di dispositivo, utente, applicazione che richiede il dato, luogo dove si trova il client, ora nel quale viene fatta la richiesta, comportamento della sorgente, stato (compliance) della sorgente;
• identificare il mezzo con il quale la richiesta arriva (Internet, VPN, rete privata, crittografia…);
• identificare il dato richiesto e l’operazione richiesta.

Although there are technologies today capable of implementing almost all (but not all) of the features required by the Zero Trust approach, the cost and complexity of these technologies are beyond the reach of almost all organizations. And I believe I’m being optimistic.

One example stands out: it is evident that there is a need to define access policies on a system-by-system basis. This can be done through microsegmentation systems. However, all the companies I know are unable to identify which application traffic flows currently pass within their large server networks.

If we are not able to define the application flows necessary for the business to operate, we are not able to verify or limit them.

Assume breach design

Veniamo quindi al paradigma assume breach applicato al design. L’idea alla base è piuttosto semplice: le mie scelte architetturali sono guidate dalla valutazione del rischio di un eventuale breach. Potremmo chiamarla risk-based design, ma, a mio parere, il nome sarebbe meno efficace.

Ci sono due premesse importanti:

• È necessario saper valutare, nel dettaglio, gli attack path possibili contro l’infrastruttura.
• È necessario saper valutare l’impatto di eventuali compromissioni sul business.

Il primo punto richiede competenze offensive specifiche che sono diverse da quelle di chi disegna a difende una infrastruttura. Chi non si avvale di queste competenze commetterà degli errori sostanziali nel progettare le difese.

Il secondo punto richiede di saper effettuare una Business Impact Analysis (BIA) per ciascun scenario di attacco.

Solo a valle di queste valutazioni possiamo valutare quali difese implementare. In questo senso Defense in Depth e ZTA sono conseguenze di Assume Breach Design e non le premesse.

Ritorno all’esempio di reti server particolarmente vaste che contengono backend e database per tutte le applicazioni aziendali. La conseguenza di questo design è che se uno viene compromesso, l’attacker può spostarsi con relativa facilità a tutti i sistemi critici aziendali. Se valutiamo correttamente questo scenario, ci rendiamo conto che non è accettabile. Possiamo a questo punto implementare una tecnologia di microsegmentazione e provare a ridurre i flussi di traffico tra questi host. Ma possiamo anche valutare tecnologie di monitoraggio che ci permettono di identificare anomalie di traffico. Entrambi gli approcci hanno pro e contro, e non esiste una soluzione che si adatta a qualsiasi contesto. La valutazione del rischio sul business ci aiuta a determinare il budget disponibile e di conseguenza possiamo selezionare la soluzione che meglio si adatta al nostro contesto.

Posso quindi scindere ZTA in parti e decidere dove è importante. La decisione è basata su un’analisi di rischio su scenari di attacco: in altre parole Assume Breach Design.

Post breach

Tutte le infrastrutture che conosco sono cresciute in modo graduale e non strutturato. In altre parole non esiste mai una documentazione che descrive come l’infrastruttura, in termini di server, applicazioni, è stata creata. Da una parte il compito sarebbe impossibile con strumenti tradizionali, dall’altra parte il paradigma assume breach ci impone di riflettere su come reagiremo ad un attacco.

Nella quasi totalità dei casi (e sono ottimista) se ci accorgiamo di un attacco in corso all’interno della nostra infrastruttura, non siamo in grado di dire con certezza fin dove l’attacco si è spinto. In altre parole non sappiamo come eradicare l’attacco dall’infrastruttura a meno di ricostruirla completamente.

Il paradigma di Infrastructure as Code ci può aiutare a costruire la nostra infrastruttura (o parte di essa) partendo da file testuali. L’uso di microservizi e container ci permette la stessa cosa in ambito applicativo. Se iniziamo ad abbracciare questa mentalità ci accorgiamo che possiamo ricostruire l’infrastruttura completa in ogni istante e che il processo ci costruzione può servire da documentazione.

I vantaggi sono immediati: documentazione, standardizzazione, compliance… La complessità degli strumenti è tuttavia un limite all’adozione per molte organizzazioni. La rigidità dell’infrastruttura è in realtà un problema apparente che rende evidente il caos operativo.

Conclusioni

L’approccio Assume Breach Design vuole riportare il business al centro delle decisioni. L’infrastruttura esiste per servire uno scopo: il business dell’azienda. Le protezioni che i team tecnici decidono oggi, vengono implementate per salvaguardare il business dell’azienda.

Rimettere il business al centro significa spostare la Cybersecurity da una cosa per tecnici ad una necessità aziendale.

Per troppi anni ho visto reparti IT considerati come un buco nero che assorbe budget. Gli effetti di questa mentalità sono sotto gli occhi di tutti. Forse è tempo di cambiare.