La gestione della fiducia (“trust management”) costituisce, probabilmente, il componente più importante di una rete Zero Trust Security.
Conosciamo tutti la fiducia in una certa misura: ci fidiamo dei membri della nostra famiglia, ma non di un estraneo per strada, e certamente non di un estraneo che sembri minaccioso, inquietante o dallo sguardo torvo. Perché? Per cominciare, riflettiamo un attimo sulla nostra famiglia. Salvo le famiglie disfunzionali, conosciamo molto bene i membri della nostra famiglia: sappiamo che aspetto hanno, dove vivono, e più o meno cosa fanno tutto il santo giorno. Non abbiamo dubbi su di loro ed è più probabile che ci fidiamo di essi per le questioni davvero importanti.
Uno straniero, d’altra parte, è qualcuno che tendenzialmente ci è completamente sconosciuto. Osservando il suo volto potremmo essere in grado di ipotizzare alcune cose su di lui, ma non sappiamo dove e come sia vissuto, e non conosciamo la sua storia, e soprattutto, probabilmente non faremmo affidamento su di uno sconosciuto per questioni importanti.
Generalmente raccogliamo tutte le informazioni che possiamo sullo sconosciuto (da ciò che dice e come lo dice, dai termini del suo lessico, ma anche dalla prossemica e dal linguaggio del suo corpo), decidendo inconsciamente quanto sia o meno affidabile.
Faremmo entrare in casa uno sconosciuto se dovesse chiederci di fare una telefonata sostenendo di esser stato appena aggredito davanti il vialetto di casa nostra? Quali sono gli automatici processi cognitivi che attuiamo per appurare se lo sconosciuto dice o meno la verità?
Dentro di noi scatta un campanellino d’allarme, un processo decisionale per aiutarci a discernere l’ipotesi-verità: il tizio mente, o è stato effettivamente vittima di un’aggressione (e quindi merita il nostro aiuto)?
Zero Trust Security: cos’è, quali sono i principi cardine e i fondamenti applicativi
Indice degli argomenti
Il concetto di fiducia nella Zero Trust Security
Il concetto di fiducia in una Rete ZTS sembra contraddittorio, eppure, analogamente al cognitivismo umano, è importante capire che là dove non abbiamo fiducia intrinseca in una Rete, dobbiamo procurarcela in qualche modo, e gestirla e vagliarla periodicamente con cura.
C’è però un piccolo inconveniente: l’operatore di un contesto ZTS non sarà sempre disponibile ad autorizzare e concedere fiducia! Inoltre, l’operatore semplicemente non scala.
Fortunatamente, sappiamo come risolvere questo problema, ossia deleghiamo la fiducia, come mostrato nella seguente figura.
(Un operatore ripone fiducia in un particolare sistema, che a sua volta può fidarsi di un altro, formando una catena di fiducia).
La delega della fiducia è importante perché ci consente di costruire sistemi automatizzati che possono crescere su larga scala e operare in modo sicuro e affidabile minimizzando l’intervento umano.
L’operatore ZTS dovrà assegnare un certo livello di fiducia a un sistema, abilitandolo a intraprendere azioni per conto dell’operatore.
Un semplice esempio è la scalabilità automatica. Vogliamo che i nostri server effettuino il provisioning in base alle esigenze, ma come facciamo a sapere se un nuovo server è davvero nostro e non un altro server casuale? L’operatore deve delegare la responsabilità a un sistema di provisioning, concedendogli la capacità di fargli assegnare fiducia e creare nuovi host.
In questo modo, possiamo dire di avere fiducia nel nuovo server (“trustiamo il nuovo server”), ovvero, il server è davvero nostro perché il sistema di Provisioning ha convalidato che ha intrapreso l’azione per crearlo, e il sistema di approvvigionamento può provare che l’operatore gli ha concesso la possibilità di farlo.
Questo flusso di fiducia verso l’operatore è spesso indicato come una catena di fiducia (“trust chain”) e l’operatore può essere indicato come un’ancora di fiducia (“trust anchor”).
Modelli di minaccia informatica
La definizione dei modelli di minaccia (o Cyber Threat Models) è il primo passo nella progettazione di un’architettura di sicurezza. Un threat model enumera i potenziali aggressori, le loro capacità e risorse, ed i loro possibili obiettivi.
I threat models normalmente definiscono quali attackers sono nell’ambito, scegliendo razionalmente di mitigare prima gli attacchi degli avversari più deboli, per poi passare ad avversari più difficili. Un threat model ben definito può essere uno strumento utile per concentrare gli sforzi di mitigazione contro gli attacchi.
Quando si costruiscono sistemi di sicurezza informatica, come nella maggior parte degli esercizi di Ingegneria, c’è una tendenza a concentrarsi sugli aspetti più elaborati del problema ingegneristico a scapito delle parti più noiose, ma comunque importanti.
Questa tendenza è particolarmente preoccupante in un sistema di sicurezza informatica, poiché l’anello più debole del sistema risulterà essere dove gli attackers si sposteranno rapidamente, concentrando la loro attenzione.
Pertanto, il threat model funge da meccanismo di messa a fuoco della nostra attenzione su una serie di possibili minacce, e sulla loro gestione e prevenzione.
I threat model sono utili anche quando si assegnano priorità alle iniziative di sicurezza: combattere gli attackers a livello statale non ha senso se le misure di sicurezza informatica di un certo sistema sono insufficienti perfino per difendere contro un semplice attacco a forza bruta alle password di un utente.
Quando si sta ragionando su di un threat model è fondamentale iniziare dapprima con le persone più semplici in azienda (amo definirli “ utOnti”, con cui molti di noi hanno storicamente avuto o hanno ancora a che fare nella nostra professione d’informatici).
Le tecniche per la modellazione delle minacce
Esistono tecniche diverse per la modellizzazione delle minacce nel campo della sicurezza informatica. Ecco alcune delle più popolari:
- STRIDE
- DREAD
- PASTA
- TRIKE
- VAST
Tali tecniche forniscono strutture diverse per l’esplorazione dello spazio delle minacce. Ognuna di loro persegue lo stesso obiettivo: enumerare le minacce al sistema ed enumerare ulteriormente i sistemi e i processi di mitigazione per tali minacce.
Threat models diversi affrontano il problema da diverse angolazioni. Alcuni si concentrano sulle risorse che un attacker potrebbe prendere di mira. Altri esaminano ogni componente software in isolamento, ed enumerano tutti gli attacchi che potrebbero essere applicati a quel sistema. Infine, alcuni modelli potrebbero considerare il sistema nel suo insieme dal punto di vista dell’attacker: come potrei avvicinarmi a penetrare questo sistema se fossi un attacker?
Ognuno di questi approcci ha pro e contro, ma per una mitigazione ben diversificata e strategica, è ideale una combinazione dei tre approcci.
Le metodologie di threat models
Se dovessimo esaminare la metodologia di threat model basato sull’attacker, saremo in grado di farlo classificando gli attackers in un elenco di potenzialità crescente (elenco ordinato dal meno al più minaccioso):
- attackers opportunisti. Come gli script kiddies, che altro non sono che attacker poco sofisticati che sfruttano vulnerabilità ben note, senza un preciso obiettivo aziendale.
- attacker mirati. Attackers che realizzano attacchi specializzati contro un particolare obiettivo. Lo Spear-phishing e lo spionaggio aziendale possono rientrare in questo punto.
- minacce interne. Utente di un sistema con credenziali, ma di uso quotidiano. Appaltatori e dipendenti non privilegiati generalmente ricadono in questo punto.
- interno fidato. Un amministratore di sistema (apparentemente) molto affidabile.
- attackers di Stato. Team di attackers sostenuti da governi nazionali e che si presume abbiano vaste risorse e capacità di posizionamento per attaccare un bersaglio.
La classificazione di minacce come queste è un esercizio utile per concentrare la discussione su un particolare livello contro cui mitigare. Discuteremo quali sono gli obiettivi ZTS nella prossima sezione.
Nella RFC 3552 viene descritto il threat model Internet. Le Reti ZTS in genere seguono il threat model Internet per pianificare il proprio livello di Sicurezza. Ecco un estratto pertinente della RFC:
“…l’ambiente Internet ha un Threat model abbastanza chiaro. In generale presupponiamo che i sistemi finali impiegati in uno scambio di protocollo non siano stati compromessi. La Protezione contro un attacco quando uno dei sistemi finali è già stato compromesso, infatti, è straordinariamente difficile. Tuttavia, è possibile progettare protocolli che riducono al minimo l’entità del danno causato in queste circostanze. Al contrario, assumiamo che l’attacker abbia il controllo quasi completo della comunicazione attraverso il quale comunicano i sistemi finali. Ciò significa che l’attacker potrà leggere qualsiasi PDU (Protocol Data Unit) sulla Rete, peraltro in modo non rilevabile, e rimuovere, modificare o iniettare pacchetti contraffatti via cavo o wireless. Ciò include la possibilità di generare o eliminare i pacchetti che sembrano provenire da un host affidabile. Quindi, anche se il sistema finale con cui si desidera comunicare di per sé è sicuro, Internet non fornisce alcuna garanzia che i pacchetti che affermano di provenire da quel sistema effettivamente lo siano.”
ZTS, come risultato della carenza di controlli sugli endpoint in Rete, espande il threat model Internet per considerare già compromessi gli endpoint.
Come rispondere alle minacce
La risposta a queste minacce, generalmente, è di rafforzare preventivamente i Sistemi contro le compromissioni, e adottare Sistemi di rilevamento di compromissioni.
Il rilevamento è aiutato dalla scansione dei dispositivi e dall’analisi comportamentale dell’attività da
ogni dispositivo. Inoltre, l’attenuazione della compromissione dell’endpoint viene ottenuta con frequenti aggiornamenti software sui dispositivi e sui relativi sistemi operativi, rotazione frequente e automatizzata delle credenziali, e, in alcuni casi, turnover periodico dei dispositivi stessi.
È essenzialmente impossibile difendersi da un attacker con risorse illimitate e, le Reti ZTS lo riconoscono. L’obiettivo di una Rete ZTS non è difenderci contro tutti gli avversari, ma piuttosto dai tipi di avversari che si vedono comunemente in una Rete ostile.
Conclusioni
Dalla nostra precedente discussione sulle capacità degli attackers, possiamo sostenere che una Rete ZTS tenta di mitigare dagli attacchi all’esterno, fino agli attacchi originati da una rete “trustata”, ossia tipicamente quella utilizzata da “insider”: lo sviluppo di mitigazioni contro questi tipi di attacchi ci difende contro la stragrande maggioranza dei tentativi di compromissione, e costituisce un notevole miglioramento per la Security Posture.
Le Reti ZTS generalmente non cercano di mitigare tutti i cyber threat-actors a livello statale, sebbene lo facciano tentando di mitigare quegli attacchi che tentano di compromettere i nostri sistemi da remoto.
Si presume che i threat-actors a livello statale abbiano enormi quantità di denaro, il che dà a loro la possibilità di amplificare quelle tipologie di attacchi informatici che è complesso mitigare per le PMI.
Difendersi da queste minacce è estremamente costoso, e richiede dedizione e hardware specializzato, ma la maggior parte delle Reti ZTS considera le più estreme forme di attacco (ad esempio, una vulnerabilità presente nell’Hypervisor e che, se exploitata, consentirebbe all’attacker di copiare pagine di memoria al di fuori delle VM”) fuori dall’ambito del loro tipico threat model.
Sia chiaro: le best practice sono ancora incoraggiate, ma il modello ZTS richiede che la Sicurezza delle informazioni sia utilizzata per autenticare e autorizzare azioni, come ad esempio le credenziali su disco.
Ulteriori requisiti sugli endpoint, come ad esempio la crittografia completa del disco, potranno essere applicati tramite policies aggiuntive.
