Zero Trust Security: come assegnare correttamente il livello di fiducia ai dispositivi aziendali

Quando in un’organizzazione arriva un nuovo dispositivo, generalmente gli viene assegnato un livello di fiducia (un livello di “trust”) identico a quello che si ha nel vendor o nel proprio fornitore.

Per la maggior parte delle persone rappresenta un livello di fiducia piuttosto elevato (garantito o meno), tuttavia questa “fiducia gratuita” esiste solo virtualmente ed è doveroso inoculare reale fiducia nel dispositivo stesso.

Zero Trust Security: cos’è, quali sono i principi cardine e i fondamenti applicativi

Principi base per assegnare la fiducia a un nuovo dispositivo

Esistono diversi modi per iniettare (e mantenere) questa fiducia nel dispositivo: al giorno d’oggi l’ecosistema hardware è molto vasto, e l’approccio in produzione differisce caso per caso, ma ci sono alcuni principi base che si applicano a tutti i livelli.

Questi principi riducono la maggior parte delle differenze a dettagli d’implementazione.

Immagini certificate di sistemi operativi, software e firmware

Il primo di questi principi è noto da tempo tra gli addetti ai lavori: le immagini certificate di sistemi operativi, software e firmware.

Indipendentemente da come riceviamo i dispositivi o a quale fornitore ci rivolgiamo abitualmente, dovremmo sempre far caricare su di essi solo immagini certificate: è facile installare una backdoor o un malware in un sistema operativo non verificato in origine; pertanto, piuttosto che creare immagini frettolosamente (come accade spesso in tante, tantissime aziende italiane), ha senso farlo un’unica volta ma certificando scrupolosamente il file .iso (o .bin, o .msi oppure qualsivoglia altro formato utilizzato per la distribuzione).

L’installazione di un’immagine “pulita” (ad esempio un’immagine .iso scaricata dal sito ufficiale del vendor, verificata tramite il confronto tra il checksum SHA256 dichiarato dal produttore/distributore sul suo sito e quello calcolato sull’immagine appena scaricata) su di un dispositivo, garantisce un certo grado di trust: saremo matematicamente certi che il software in esecuzione è proprio una copia clone di quello distribuito dal vendor, e per questo motivo tracciare il timestamp dell’ultima volta in cui è stata avviata un’immagine su di un certo dispositivo costituisce un buon punto di partenza per determinare il livello di fiducia che quel dispositivo otterrà nella nostra rete (tracciare i timestamp delle immagini non è un’attività appannaggio esclusivo di firmware o sistemi operativi di server e affini, ma di tutto ciò che ha potenzialmente un piede nella nostra rete: sistemi VoIP e IoT compresi, spesso dispositivi perfetti per occultare backdoor o veri e propri malware attraverso cui accedere abusivamente in azienda, si legga ad esempio il recente incidente informatico causato dai softphone 3CXDesktopApp).

Un certificato digitale per identificare un dispositivo

Certificare il software in esecuzione su un dispositivo è solo il primo passo, giacché i dispositivi dovranno successivamente identificarsi alle risorse a cui si tenterà di accedere. Questa operazione in genere viene effettuata generando un certificato digitale univoco firmato dall’Autorità di Certificazione (CA) in uso presso l’organizzazione.

Durante la comunicazione con le risorse di rete, il dispositivo presenterà il proprio certificato firmato: il certificato dimostra non solo che si tratta di un dispositivo conosciuto, ma fornisce anche un metodo di identificazione.

I dettagli incorporati nel certificato del dispositivo potranno essere abbinati ai dati contenuti nell’inventario dispositivi, che potranno essere utilizzati per ulteriori decisioni.

Fornendo un certificato firmato (mediante il quale un dispositivo può essere identificato) è necessario memorizzare in modo sicuro la chiave privata associata. Questa non è un’attività banale. Il furto della chiave privata consentirebbe a un attacker di mascherarsi da dispositivo attendibile: è lo scenario peggiore per le autenticazioni dei dispositivi.

Un modo semplice ma non completamente sicuro per farlo è configurare i diritti di accesso alla chiave in modo tale che solo l’utente più privilegiato (root o Administrator) possa accedervi; tuttavia, questo scenario costituisce un metodo di archiviazione a sua volta potenzialmente a rischio, poiché un attacker che dovesse riuscire ad ottenere un accesso elevato potrebbe esfiltrare la chiave non protetta.

Un approccio alternativo è quello di cifrare la chiave privata: è assai meglio che fare affidamento su semplici permessi, sebbene in questo caso possano presentarsi problemi di usabilità poiché sarà necessario fornire una password (o altro input segreto) per decifrare e utilizzare la chiave.

Ciò potrebbe non rappresentare un problema per un dispositivo dell’utente finale, poiché all’utente potrà essere richiesto di inserire la password, sebbene questo scenario non sia solitamente fattibile per le distribuzioni dei server in datacenter privi di un’adeguata automazione (in genere, infatti, è necessaria l’interazione di un sistemista per ogni riavvio del sistema operativo o del software).

Un approccio più ingegnoso per archiviare le chiavi del dispositivo è attraverso l’uso di crittoprocessori. Questi dispositivi, comunemente indicati come HSM (Hardware Security Module) o TPM (Trusted Platform Module), sono muniti di un’area protetta in cui è possibile eseguire operazioni crittografiche: forniscono un’API ad accesso limitato che può essere utilizzata per generare chiavi di crittografia asimmetriche, in cui la chiave privata non lascia mai il modulo di sicurezza.

Dal momento che nemmeno il sistema operativo può accedere direttamente a una chiave privata memorizzata da un modulo di sicurezza, sono estremamente difficili da esfiltrare.

Sicurezza dell’identità nei sistemi statici e dinamici

In sistemi relativamente statici è normale che un operatore sia coinvolto quando viene effettuato il Provisioning di nuovi host.

Ciò semplifica la storia della distribuzione: il tecnico di fiducia può generare direttamente le nuove chiavi per conto degli host.

Naturalmente, man mano che l’infrastruttura cresce, questo sovraccarico diventerà problematico.

Nell’automazione del processo di provisioning e firma è necessario prendere una decisione fondamentale: dovrebbe essere coinvolto un tecnico per la firma di nuovi certificati digitali? La risposta a questo dipende in gran parte dal livello di attenzione ai temi della cyber security che c’è in quell’organizzazione: un certificato digitale di dispositivo firmato ha un certo grado di potere, e servirà a identificare quel dispositivo come autentico e affidabile.

Proprio come vengono adottate misure precauzionali per proteggere i furti localmente, dovremmo proteggerci dalla loro frivola generazione da parte di personale inaffidabile o superficiale.

Se il provisioning è automatizzato ma comunque guidato da un tecnico, ha senso consentirgli di autorizzare anche la richiesta di firma associata: avere un collega fidato coinvolto ogni volta è il modo migliore per impedire l’approvazione di richieste non autorizzate, ergo è consigliabile che gli addetti a quest’attività lavorino in team, e che siano responsabili dell’approvazione delle sole richieste che essi stessi hanno avviato.

È possibile eseguire il provisioning e l’autorizzazione della firma in un unico passaggio tramite l’uso di una password monouso temporanea (TOTP).

La TOTP potrà essere fornita insieme alla richiesta di provisioning, e trasmessa al servizio di firma per la verifica. Questo meccanismo semplice ma efficace consente un controllo umano sulla firma digitale di nuovi certificati, limitando al minimo il sovraccarico amministrativo.

Poiché una TOTP può essere utilizzata una volta sola, un eventuale errore di verifica TOTP costituirà un importante evento di Sicurezza informatica.

Superfluo scrivere che nulla di tutto questo si applica se l’obiettivo è quello di automatizzare completamente il provisioning di nuovi host.

I sistemi che supportano il ridimensionamento automatico (o “auto-scaling”, ossia che possono crescere e ridursi) si trovano generalmente in installazioni di grandi dimensioni estremamente automatizzate.

Consentire a un sistema di ridimensionarsi da solo può ridurre significativamente la quantità di alimentazione e di manutenzioni necessarie, consentendoci di diminuire spese amministrative nonché costi operativi di gestione.

La firma di un certificato digitale è un’operazione che richiede molta fiducia, e proprio come con altri componenti ZTS, questa fiducia deve provenire da qualche parte. Tre sono le opzioni più diffuse:

• un tecnico;
• un gestore delle risorse;
• il dispositivo o l’immagine.

Una scelta facile e verosimilmente affidabile per un’infrastruttura relativamente statica è quella di preferire un tecnico, ma è un’opzione pessima se stiamo ragionando in termini di infrastrutture automatizzate: in questo caso, infatti, è più sensato scegliere il gestore delle risorse o l’immagine o entrambi.

Il gestore delle risorse occupa una posizione privilegiata: ha infatti la capacità di far crescere e ridurre l’infrastruttura, ed è in grado di influenzarne la disponibilità.

Fornisce un buon equivalente di un tecnico in un sistema più statico, ed è in grado di affermare tempestivamente “Oggi ho attivato questo nuovo host, e ti mostro tutto quello che conosco al suo riguardo”: può utilizzare questa posizione per autorizzare direttamente o indirettamente la firma di un nuovo certificato.

A seconda delle proprie esigenze, potrebbe essere opportuno non concedere questa capacità interamente al Gestore delle risorse: in questo caso, le credenziali possono essere inserite in un’immagine, tuttavia lo sconsiglio come meccanismo principale, in quanto da una parte attribuisce troppa responsabilità all’archivio immagini, d’altra parte proteggere e ruotare le immagini può rivelarsi un’attività insidiosa.

In modo simile, i moduli HSM o TPM possono essere utilizzati per fornire un certificato digitale del dispositivo legato all’hardware: è un approccio più astuto che incorporare chiavi nell’immagine, anche se chiedere a un dispositivo supportato da TPM di firmare un nuovo certificato digitale non è ancora l’ideale, soprattutto se si considerano alcuni scenari di distribuzioni basati sul Cloud Computing.

Un buon approccio per mitigare queste preoccupazioni è di avvalersi sia del Gestore delle risorse che di un’immagine/dispositivo attendibile.

Il materiale di autenticazione generico integrato nell’immagine (o in una chiave TPM registrata) può essere utilizzato per proteggere la comunicazione con il servizio di firma e può fungere da componente in un’autorizzazione multiforme.

Di seguito sono riportati esempi di componenti da considerare per l’autorizzazione:

1. chiavi TPM o chiavi immagini registrate;
2. indirizzi IP corretti;
3. TOTP validi (ossia generati dal Gestore delle risorse);
4. proprietà attese dei certificati digitali (come, ad esempio, la validazione del classico campo cn, common name).

Effettuando la convalida di questi punti autorizzativi, il servizio di firma del certificato potrà essere verosimilmente certo che la richiesta sia legittima. Il Gestore delle risorse da solo non può richiedere un certificato, e poiché non ha accesso agli host di cui esegue il Provisioning, il massimo che un attacker potrebbe fare è influire sulla disponibilità. Allo stesso modo, un’immagine rubata da sola non può chiedere un certificato digitale poiché dovrebbe chiedere al Gestore delle risorse di convalidare chi ha effettuato il Provisioning dell’host, il quale si aspetta una richiesta.

Autenticazione dei dispositivi attraverso il piano di controllo

Chiarito come archiviare l’identità in un nuovo host o in un dispositivo, è fondamentale capire come convalidare tale identità in Rete. Sono disponibili numerosi standard e tecnologie aperte attraverso i quali raggiungere questo obiettivo.

Accennerò a due di queste tecnologie, e del motivo per cui sono così importanti per l’Autenticazione: X.509, e successivamente, i moduli TPM. Queste tecnologie godono di diffusione e supporto pluriennale, anche se non è sempre stato così.

X.509 costituisce probabilmente lo standard più importante quando si parla d’Identità e Autenticazione dei dispositivi: definisce il formato per i certificati digitali, gli elenchi di revoche nonché i metodi attraverso i quali convalidare le catene di certificazione.

Una delle cose più interessanti di X.509 è che le coppie di chiavi pubblica/privata (che utilizza per dimostrare l’Identità) possono essere utilizzate anche per avviare la comunicazione cifrata.

Questo è solo uno dei tanti motivi per cui X.509 è così prezioso per la sicurezza in Internet: affinché un certificato digitale sia utile, deve essere attendibile. Un certificato digitale può essere creato da chiunque, quindi averne solo uno con il nome giusto non significa molto: una terza parte fidata deve approvare la validità del certificato firmandolo digitalmente.

Un certificato senza una “reale” firma è noto come certificato autofirmato (o “self-signed”) e dovrebbe essere utilizzato solo a scopi di test (sebbene in Italia non sia esattamente così… basta infatti effettuare una ricerca sul portale shodan.io usando le chiavi di ricerca “port:443 country:IT” per rendersi conto di quante aziende ed enti italiani utilizzino ancora certificati autofirmati nel 2023).

È responsabilità dell’Autorità di Registrazione (un ruolo comunemente ricoperto dall’Autorità di Certificazione) garantire che i dettagli del certificato digitale siano accurati prima di consentirne la firma.

Firmando il certificato, infatti, viene creato un collegamento verificabile dal certificato firmato al padre: se il certificato firmato ha le proprietà corrette potrà firmare ulteriori certificati, consentendo la creazione di una catena.

L’Autorità di Certificazione si trova alla radice di questa catena. Affidandoci a un’Autorità di Certificazione (CA) ci fidiamo della validità di tutti i certificati digitali firmati da essa: questa è piuttosto una comodità, poiché ci consente di distribuire in anticipo solo un piccolo numero di chiavi pubbliche, vale a dire le chiavi pubbliche della CA.

Tutti i certificati digitali forniti da lì in poi potranno essere ricollegati alla CA attendibile conosciuta, diventando anch’essi attendibili.

Il fine primario di un certificato X.509 è dimostrare l’Identità sfruttando due chiavi invece di una: una chiave pubblica e una chiave privata. La chiave pubblica viene distribuita, mentre la chiave privata è custodita dal proprietario del certificato digitale.

Il certificato X.509 stesso contiene una vasta gamma di informazioni configurabili: ha una serie di campi standard, insieme ad un ecosistema di estensioni che consentono di trasportare metadati che possono essere utilizzati per scopi autorizzativi.

Un elenco di tipiche informazioni reperibili all’interno di un certificato X.509:

1. versione del certificato digitale;
2. numero di serie;
3. algoritmo di firma del certificato digitale;
4. CA emittente;
5. validità iniziale e finale;
6. soggetto;
7. algoritmo a chiave pubblica dell’oggetto;
8. chiave pubblica dell’oggetto;
9. estensioni (ID chiave CA, ID chiave del soggetto certificato, uso della chiave del certificato, punti di distribuzione CRL ecc.);
10. algoritmo di firma del certificato digitale;
11. valore della firma del certificato digitale;
12. impronte digitali (SHA-1, SHA-256 ecc.).

Certificato X.509 adottato dal portale Red hat: dettagli sulla CA emittente.

X.509 si occupa di coppie di chiavi anziché di una singola chiave. Sebbene sia estremamente comune che si tratti di coppie di chiavi RSA, non è obbligatorio, infatti X.509 supporta coppie di chiavi asimmetriche generabili attraverso diversi algoritmi.

Ad esempio, il seguente portale utilizza crittografia a curve ellittiche (ECC) come è chiaramente indicato nel suo certificato digitale, mentre l’algoritmo ECDSA è utilizzato per la firma stessa del certificato:

Certificato X.509 adottato dal Cloud Provider digitalOcean.com: l’algoritmo asimmetrico in questo caso sfrutta crittografia a curve ellittiche.

X.509 è fondamentale per autenticare dispositivi, ma non risolve tutti i problemi: funziona con una chiave privata, e quella chiave privata va protetta. Se venisse compromessa, anche l’identità e la privacy del dispositivo diventerebbero vulnerabili (qualcuno rammenta il caso della (ex) CA DigiNotar finita in bancarotta dopo aver subito il furto della sua chiave privata?).

Le chiavi private possono essere cifrate quando vengono archiviate, richiedendo una password per la decrittazione: quella appena descritta costituisce più che una buona pratica d’uso, poiché a un eventuale attacker verrà richiesto qualcosa di più di un semplice accesso a disco per risalire alla chiave privata, ma risulta pratica solo per i dispositivi rivolti all’utente.

Nei datacenter la crittografia della chiave privata non risolve definitivamente il problema poiché occorre ancora memorizzare la password, o in qualche modo trasmetterla al server, e a quel punto la password diventa ingombrante quanto la chiave privata stessa.

I Moduli di Sicurezza Hardware (HSM) contengono dispositivi in grado di generare una coppia di chiavi pubblica/privata archiviando poi la privata in una memoria sicura. Sebbene esistano attacchi anche contro tecnologia HSM, di norma non è possibile leggere la sua chiave privata: è possibile solo chiedere all’HSM di eseguire un’operazione per nostro conto. In questo modo la chiave privata non può essere rubata in quanto è protetta a livello hardware.

L’applicazione di X.509 all’Autenticazione dei dispositivi in una rete ZTS coinvolge un campo molto vasto: costituisce una pietra miliare per dimostrare l’Identità del dispositivo per quasi tutti i protocolli, ed è fondamentale nell’applicazione di crittografia end-to-end.

Ogni singolo dispositivo in una rete ZTS dovrebbe essere dotato di un certificato X.509. C’è però una considerazione importante da fare: stiamo usando X.509 per autenticare un dispositivo, ma il cuore dell’intero schema, la chiave privata, è decisamente basata su software.

Se la chiave privata venisse rubata, l’intera faccenda dell’Autenticazione del dispositivo diventerebbe un castello di sabbia! I certificati digitali vengono spesso utilizzati anche come proxy per la vera Autenticazione dei dispositivi, poiché le chiavi sono così lunghe e ingombranti che non ne memorizzeremmo mai una a memoria.

Vengono scaricate e installate, e proprio per questo motivo non tendono a seguire gli utenti in giro, ma in genere seguono i dispositivi. Anche se qualcuno potrebbe stabilire che il rischio associato al problema della chiave privata è accettabile, si tratta comunque di un problema serio, in particolare per le reti ZTS.

Fermo restando la problematica appena descritta, vediamo ora alcuni approcci percorribili con cui è possibile associare (avvalendosi di moduli TPM) inestricabilmente una chiave privata con dell’hardware.

Moduli TPM

Un modulo TPM (Trusted Platform Module) è un particolare chip incorporato in un dispositivo di elaborazione. Chiamati anche crittoprocessori, questi chip si avvalgono di un proprio firmware e sono dedicati all’esecuzione di operazioni crittografiche in modo affidabile e sicuro.

Fornendo servizi per le operazioni crittografiche ed escludendo le interfacce per il recupero delle chiavi private, si ottiene una parte di quella Sicurezza informatica di cui c’è tanto bisogno senza mai esporre le chiavi segrete al sistema operativo, poiché i moduli TPM sono legati all’hardware.

Questo è un aspetto molto importante, ed è il motivo principale per cui i TPM sono così fondamentali per l’Autenticazione dei dispositivi nelle reti ZTS. Diversi framework software per l’Identità e l’Autenticazione (come X.509) fanno molto per l’Autenticazione del dispositivo, ma senza un modo per associare definitivamente la chiave software al dispositivo hardware che si sta tentando di identificare, non potremmo chiamarla “Identità del dispositivo” con piena convinzione.

I TPM risolvono questo problema, fornendo l’associazione necessaria.

I moduli TPM generano e archiviano quella che è nota come radice di archiviazione (o SRK): questa coppia di chiavi rappresenta la radice di attendibilità per il dispositivo TPM in questione. I dati cifrati utilizzando la relativa chiave pubblica potranno essere decifrati solo dal TPM di origine.

Il lettore con un minimo di competenze in Crittografia potrebbe mettere in dubbio l’utilità di questa funzione nell’applicazione della cifratura dei dati in blocco: gli addetti ai lavori sanno che le operazioni crittografiche asimmetriche sono molto impegnative in termini computazionali, quindi non adatte alla cifratura di pezzi di dati relativamente grandi, pertanto, per cifrare dati in blocco per sfruttare il TPM occorre ridurre la quantità di dati di cui SRK è responsabile per la protezione.

Un modo semplice per eseguire questa operazione consiste nel generare una chiave crittografica casuale, cifrare i dati in blocco usando crittografia simmetrica con prestazioni note (ad esempio con l’algoritmo AES) e quindi utilizzare SRK per cifrare la chiave risultante: questa strategia, illustrata nella seguente figura,

I dati vengono cifrati con una chiave AES, che a sua volta viene cifrata dal modulo TPM.

garantisce che la chiave crittografica usata per la cifratura non possa essere recuperata, a meno che non sia presente il TPM che la proteggeva in origine.

Molte librerie (ad esempio come TrouSerS) creano chiavi intermedie durante la cifratura dei dati utilizzando il modulo TPM. Cioè, chiedono al TPM di creare una nuova coppia di chiavi asimmetriche, utilizzare la chiave pubblica per cifrare la chiave AES, infine utilizzare SRK per cifrare la chiave privata.

Quando si decifreranno i dati sarà necessario prima decifrare la chiave privata intermedia, utilizzarla per decifrare la chiave AES, infine decifrare i dati originali.

Questa implementazione può sembrare strana, ma ci sono alcune valide ragioni per cui non lo è. Uno dei motivi è che il livello aggiuntivo indiretto di cifratura consente una maggior flessibilità nella distribuzione dei dati protetti.

Sia la chiave SRK che quella intermedia supportano le passphrase, quindi, l’uso di una chiave intermedia consente l’uso di una passphrase aggiuntiva, forse più conosciuta. Questo può o non può avere senso per la tua particolare distribuzione.

Ai fini di “Questa chiave dovrebbe essere decifrabile solo su questo dispositivo”, è preferibile (oltre che più performante) ignorare l’uso di una chiave intermedia. L’applicazione più importante per l’archiviazione sicura supportata da TPM è la protezione della chiave privata X.509 del dispositivo: tale chiave segreta serve a dimostrare in modo inequivocabile l’Identità del dispositivo e, se dovesse essere rubata, lo sarebbe anche l’identità.

Cifrare la chiave privata utilizzando TPM significa che mentre la chiave potrebbe ancora essere prelevata dal disco, non sarà recuperabile senza l’hardware originale.

Attenzione, perché la cifratura della chiave privata del dispositivo nonché il wrapping della chiave con l’SRK non pongono definitivamente al riparo dagli scenari di furto. Proteggono la chiave dall’esser letta direttamente dal disco, tuttavia un attacker con privilegi elevati potrebbe comunque essere in grado di leggerla dalla memoria o semplicemente di chiedere al modulo TPM di eseguire l’operazione per lui.

I prossimi paragrafi forniscono ulteriori approcci su come convalidare ulteriormente l’Identità hardware (intendo oltre all’Identità X.509)

Registri di configurazione della piattaforma

I registri di configurazione della piattaforma (o PCR, acronimo di Platform Configuration Registers) costituiscono una funzionalità essenziale dei moduli TPM. Forniscono spazi di storage in cui vengono archiviati gli hash del software in esecuzione. Un tipico PCR ospita inizialmente l’hash del BIOS, poi il record di avvio, successivamente la sua configurazione e così via.

Questa sequenza di hash può quindi essere utilizzata per attestare che il sistema si trova in uno stato approvato e/o in una certa configurazione. Di seguito è riportato un esempio dei primi registri archiviati nel TPM:

Questo è utile per diversi aspetti, ma soprattutto per garantire che solo le configurazioni software autorizzate possano decifrare i dati.

Questa operazione può essere eseguita passando un set di valori PCR noti quando si utilizza il TPM per cifrare alcuni dati: è nota come “sigillatura” dei dati. I dati sigillati potranno essere decifrati solo dal modulo TPM che li ha sigillati originariamente, e solo se i valori PCR corrispondono.

Poiché i valori del PCR non possono essere modificati o ripristinati, possiamo utilizzare il sigillo TPM per garantire che i nostri dati segreti non siano solo ancorati sul dispositivo, ma anche vincolati su una specifica configurazione e versione di software.

Questo approccio salvaguarda dalla possibilità che un attacker tenti di utilizzare l’accesso al dispositivo per ottenere la chiave privata, poiché solo il software non modificato e approvato può sbloccarlo.

Attestazione remota

Fino a quando una chiave privata continuerà ad essere archiviata al di fuori di un TPM fisico, sarà verosimilmente possibile esfiltrarla. Questo scenario di vulnerabilità permane poiché tutto ciò che serve per recuperare la chiave privata è convincere il TPM a sbloccarla anche una sola volta. Quest’azione rivelerebbe la chiave privata effettiva, azione che non è possibile quando è archiviata nel TPM.

Progettualmente i moduli TPM forniscono un modo per identificarla in modo univoco: si tratta di un’altra coppia di chiavi definita “chiave di Verifica dell’autenticità” (o EK, Endorsement Key) e ogni TPM ne ha una univoca. Il componente privato di una coppia di chiavi EK è annegato sempre e solo nel TPM stesso, quindi, rimane completamente inaccessibile al sistema operativo.

L’attestazione remota è un metodo mediante il quale il TPM genera uno stream chiamato “citazione”, che viene trasmesso in modo sicuro a una parte remota. La citazione include un elenco di valori PCR attuali, firmati utilizzando l’EK: una parte remota potrà utilizzare l’elenco per affermare sia l’identità dell’host (poiché l’EK è univoco per il TPM) sia lo stato/configurazione del software (poiché le PCR non possono essere modificate).

L’approccio più comune per supportare i dispositivi legacy in una rete ZTS consiste nell’utilizzare un proxy di Autenticazione, in grado di terminare la relazione ZTS inoltrando la connessione all’host precedente.

Sebbene sia possibile applicare la policy tra il proxy di Autenticazione e il back-end legacy, questa modalità operativa non è consigliata poiché vulnerabile ad alcuni vettori di attacco analoghi a quelli che inficiano le reti perimetrali tradizionali.

Quando si ha a che fare con dispositivi legacy è consigliabile spingere il punto di terminazione ZTS il più vicino possibile al dispositivo: nel 2023 un proxy di Autenticazione è probabilmente l’opzione più ragionevole, abbinandolo a un dispositivo hardware dedicato.

Offrendo un chip TPM e collegandosi direttamente alla porta Ethernet di un dispositivo legacy, tale dispositivo potrà fungere da supplicant ZTS. L’associazione dei due in un sistema di Inventory Management può consentire un’integrazione efficiente in una rete ZTS: sono molte le applicazioni che trarrebbero vantaggio da quest’architettura, in primis i sistemi SCADA e HVAC.

Inventory Management

L’Autenticazione dell’Identità e dell’Integrità di un dispositivo coopera notevolmente alla Cybersecurity di una rete ZTS, ma essere in grado di identificare un dispositivo come appartenente all’organizzazione è solo una parte della sfida. Sono molte altre le informazioni di cui abbiamo necessità per determinare la policy più adatta per prendere decisioni applicative sensate.

La gestione dell’Inventario comporta la catalogazione minuziosa dei dispositivi e delle loro proprietà, e il mantenimento dei relativi record è imprescindibile sia per la gestione dei server che per i dispositivi client: è più lungimirante pensare ai sistemi come a dispositivi già in rete piuttosto che solamente a dispositivi fisici isolati, poiché anche se in effetti sono solo dispositivi fisici o virtualizzati, presto o tardi potrebbero anche essere collegati in rete.

Ad esempio, a seconda delle esigenze, è auspicabile che una macchina virtuale (VM) o un container possano essere considerati anch’essi un dispositivo. Dopotutto sono dotati di molte analoghe proprietà descrittive che potrebbe avere un server fisico.

Raggruppare tutto il traffico di rete delle VM da un singolo host in un’unica policy ci riporta al modello perimetrale, invece, il modello ZTS sostiene che i carichi di lavoro debbano essere monitorati per poter guidare le policy di rete di cui abbiamo necessità.

Questo database d’inventario (o carico di lavoro, o “workload”) può essere personalizzato per adattarsi agli elevati tassi di modifica che subiscono gli ambienti virtualizzati/containerizzati.

Pertanto, sebbene il tradizionale sistema di gestione dell’inventario e lo Scheduler del workload siano sistemi differenti, possono comunque funzionare insieme; ad esempio uno Scheduler può agire come una sorta di sistema di gestione dell’Inventario, come mostrato nella seguente figura.

Uno Scheduler e un database per la gestione delle configurazioni fungono da archivi d’inventario per il piano di controllo.

Non è raro operare con più sistemi di gestione dell’inventario.

Ad esempio, molte aziende dispongono sia di software per la gestione delle Risorse che di sistemi di gestione delle configurazioni. Entrambi archiviano i metadati del dispositivo che sono utili ai nostri fini: memorizzano set diversi, raccolti in modi differenti.

Molti sistemi di gestione delle configurazioni, come Chef o Puppet, offrono modalità di gestione in cui i dati dei nodi vengono mantenuti in un database centralizzato. Nomi degli host, indirizzi IP e tipi di server sono esempi del tipo di informazioni che si trovano tipicamente in un database supportato da CM.

Utilizzare la gestione delle configurazioni in tal modo costituisce un primo passo, semplice ma funzionale, verso lo sviluppo di un database d’inventario centralizzato e aggiornato.

Uno dei grandi vantaggi nell’utilizzo di una Rete ZTS è che facendo le cose per bene, sapremo cosa aspettarci dal traffico di rete.

Dispositivi attendibili possono veicolare le aspettative nel sistema, inducendo quindi il blocco per impostazione predefinita (by default) di tutti i livelli di accesso: sono perciò consentite solo le richieste e le azioni previste dai progettisti, e un database d’inventario è un componente chiave per la realizzazione di questa capacità.

Un’enorme quantità di informazioni su cosa aspettarsi può essere generata da questi dati: informazioni come “quale utente o applicazione dovrebbe essere in esecuzione su di un certo dispositivo”, in “quali posizioni ci aspettiamo che si trovi” o il “tipo di sistema operativo” possono essere utilizzate per stabilire piani e compiti precisi.

Nei data center queste aspettative possono essere molto rigide: ad esempio, durante il Provisioning di un nuovo server possiamo definire preventivamente quale indirizzo IP verrà assegnato, in quale VLAN ed a quale scopo.

Possiamo utilizzare tali informazioni per definire precise ACL di rete e/o di firewalling basate su host, creando eccezioni per quello specifico indirizzo IP nel momento in cui dovesse effettivamente rivelarsi necessario.

In questo modo possiamo bloccare tutto il traffico di rete non autorizzato, consentendo meticolosamente solo i flussi che occorrono e che ci aspettiamo. Più proprietà possiamo immaginare e schedulare, e più in profondità potremo effettuare controlli e schedulare piani.

Tuttavia, questo non costituisce uno scenario sempre facile per i sistemi dei clienti. I clienti operano spesso in modi nuovi e inattesi, e sapere esattamente e anticipatamente cosa aspettarsi da loro è quanto meno utopia.

I server nel data center hanno spesso connessioni relativamente statiche e di lunga durata utilizzate da un insieme ben definito di host o servizi. Al contrario, i clienti tendono a stabilire molte connessioni di breve durata a una varietà diversificata di servizi, i cui tempi frequenza e modelli possono variare in modo organico.

Per affrontare la natura anarchica dei sistemi dei clienti abbiamo bisogno di un approccio diverso: un modo per farlo, ad esempio, è consentire l’accesso globale al servizio solo attraverso connessioni TLS reciprocamente autenticate (protocollo mTLS), costringendo il client a fornire un certificato digitale del dispositivo ancor prima di poter comunicare con il servizio effettivo.

Il certificato del dispositivo (client) sarà utilizzato per cercare il dispositivo nel database dell’Inventario, determinando se è autorizzato o meno a proseguire. Il vantaggio è che molti sistemi supportano già l’mTLS, e non è necessario un software client specializzato, in modo tal da fornire una sicurezza informatica ragionevolmente forte senza ostacolare più di tanto l’Accessibilità o l’Usabilità.

Uno svantaggio significativo di questo approccio, tuttavia, è che il servizio sarà raggiungibile globalmente. La richiesta di certificati client è un ottimo modo per mitigare questo pericolo, tuttavia, vulnerabilità come Heartbleed sono lì a rammentarci che la superficie di attacco di un server TLS è relativamente ampia.

Inoltre, l’esistenza delle risorse può essere scoperta semplicemente scansionandole, poiché possiamo comunque parlare in TCP con la risorsa prima di avviare il processo di Autenticazione. Come possiamo assicurarci di non coinvolgere client inaffidabili o in vera e propria malafede? Ci deve essere qualche comunicazione non attendibile, dopo tutto. Cosa viene prima dell’Autenticazione?

Avvio in sicurezza

La prima connessione da un dispositivo sconosciuto è sempre di natura dubbia, nel senso che è vero che i pacchetti contatteranno un numero di porta server (sempre se non si tratta di traffico ICMP), ma se non stiamo parlando di connessioni fortemente autenticate, siamo in presenza di un potenziale rischio.

Pertanto, il primo sistema che viene contattato da un nuovo dispositivo necessita di un meccanismo mediante il quale sia possibile autenticare questa connessione iniziale. Questo meccanismo è comunemente noto come Avvio in sicurezza.

È il processo attraverso il quale una nuova entità viene introdotta in un contesto sicuro (e quindi già trustato) in modo che la fiducia (il livello di trust) venga trasferita.

Ci sono molti modi in cui può essere effettuato questo trasferimento; il metodo attraverso il quale un operatore passa un codice TOTP a un fornitore per autorizzare una richiesta di certificato è un esempio di Avvio in sicurezza.

Nel momento in cui sto scrivendo probabilmente il miglior modo per realizzare un Avvio in sicurezza è quello di stabilire un’aspettativa, ossia coinvolgendo una terza parte fidata che abbia la capacità di introdurre nuovi sistemi.

Questa terza parte fidata si occupa di coordinare/convalidare le specifiche del sistema da introdurre, stabilendo le appropriate aspettative.

Quali sono le caratteristiche di un Avvio in sicurezza?

1. monouso: le credenziali e i privilegi associati all’Avvio sicuro devono essere tali da impedire a un utente malintenzionato di compromettere o riutilizzare la chiave;
2. breve durata: le credenziali e i privilegi associati all’introduzione dovrebbero scadere velocemente, impedendo l’accumulo di chiavi valide ma non utilizzate;
3. separazione: sfruttare una terza parte fidata per l’introduzione consente la separazione dei compiti (principio della “Separation of Duties”, estremamente trascurato da molte organizzazioni italiane, private e non), impedisce l’introduzione di pessime pratiche di (in)sicurezza informatica, e allevia i problemi operativi.

Rinnovo del trust del dispositivo

È fondamentale abituarsi all’idea che nessun livello di Sicurezza informatica è ineccepibile, neanche quello della tua organizzazione: una volta che siamo d’accordo su questo, possiamo iniziare a mitigarne le conseguenze.

La storia dei software e delle scoperte in ambito Hacking ci insegna che più a lungo un dispositivo è operativo, maggiori sono le probabilità che vengano ingegnerizzati modi e strumenti per comprometterlo.

Questo è il motivo per cui l’“anzianità” del dispositivo è un segnale di fiducia fortemente ponderato, e sempre per questo motivo la rotazione è imprescindibile. In un precedente articolo citavo la necessità salvifica della rotazione delle credenziali degli utenti, ma i dispositivi non sono diversi.

Naturalmente questa rotazione si manifesta in modi diversi a seconda della definizione di “dispositivo” nella tua organizzazione.

Se la tua infrastruttura ICT viene eseguita in Cloud, probabilmente un “dispositivo” per te è solo un’istanza host, e in questo caso la rotazione è semplice: basta spegnere l’istanza e crearne una nuova (stai usando sistemi per la Gestione delle Configurazioni, vero?).

Viceversa, se utilizzi abitualmente hardware fisico, questa pratica non è poi così banale. Il reimaging è un buon modo per ruotare un dispositivo: è un’operazione sistemistica triviale, ma con cui è possibile rimuovere tempestivamente la maggior parte delle minacce informatiche persistenti ad oggi in circolazione.

Ci si può fidare di un dispositivo appena ricreato più di uno che funziona da un anno. Sebbene il reimaging non sia immune dagli attacchi hardware o da altri attacchi di basso livello come quelli mostrati nella seguente figura,

Un’immagine del disco abbraccia le sezioni in cui possono annidarsi la stragrande maggioranza dei malware.

costituisce un ragionevole compromesso negli ambienti lavorativi in cui la rotazione fisica è osteggiata. La cyber security del data center e della supply chain mitiga parzialmente questa minaccia.

Quando si tratta di gestire dei dispositivi client, diventa tutto un altro cinema: abituarsi a una postazione client diversa è straordinariamente scomodo per gli utenti. Personalizzano il dispositivo nel tempo, rendendone complicata la salvaguardia in modo sicuro ed efficace.

Spesso, quando viene fornito un nuovo dispositivo vogliono trasferirvi la vecchia immagine. Questa non è una buona notizia per i sistemisti che cercano di preservare i dispositivi client, e un approccio risolutivo dipende in gran parte dal tuo caso d’uso: tutti concordano sul fatto che i dispositivi client debbano essere ruotati, ma la frequenza dipende dalla tua organizzazione e dal contesto in cui opera.

C’è una relazione importante da tenere a mente: meno di frequente un dispositivo viene ruotato o ne viene reinstallata l’immagine, più penetrante dovrà essere la sicurezza dell’endpoint.

Senza le garanzie (relativamente forti) di sicurezza del dispositivo che otteniamo attraverso la rotazione, occorre cercare altri metodi per rinnovare la fiducia in un dispositivo che funziona da molto tempo: in particolare possiamo farlo attraverso due tecniche, la misurazione locale e quella remota.

Misurazione locale

Può essere supportata da hardware o da software. La misurazione locale basata su hardware è più sicura e affidabile, ma ha capacità limitate.

Quella supportata da software è assai meno affidabile, ma praticamente illimitata nelle sue capacità di misurazione. Una buona opzione per la misurazione locale supportata dall’hardware è sfruttare il TPM per l’attestazione remota.

L’attestazione remota utilizza un dispositivo hardware per fornire una risposta firmata che delinea gli hash del software attualmente in esecuzione su quella macchina. La risposta è molto affidabile e difficile da riprodurre.

Tuttavia, in genere fornisce solo un’immagine del software di basso livello o del software specificamente mirato: se un attacker riuscisse a far eseguire un processo non autorizzato in userspace, il modulo TPM non sarebbe particolarmente utile per il suo rilevamento.

La misurazione locale supportata da software, viceversa, comporta un agent installato sull’endpoint che viene utilizzato per segnalare le misurazioni di stato e integrità.

Può presentarsi in forme diverse, da un client antivirus centralizzato agli agent di applicazione dei criteri di dominio.

Questi agent fanno di tutto per attestare e dimostrare la validità delle misurazioni che riportano, ma anche una mente approssimativa può giungere alla conclusione che questi sforzi sono generalmente inutili: le misurazioni supportate da software, infatti, non dispongono della protezione fornita dalle misurazioni hardware, e un attacker con privilegi sufficienti potrebbe sovvertire sistemi che si avvalgono di agent software.

Misurazione remota

È la migliore tra le due opzioni poiché beneficia della separazione dei compiti. Falsificando le informazioni per nascondere l’attacker, un host compromesso segnalerà tutto nella norma, evitando accuratamente di instillare sospetti.

Questo non è possibile con la misurazione remota o passiva, poiché un sistema completamente diverso analizza e comunica la stato dell’host in questione. Tradizionalmente, la misurazione remota viene eseguita come una semplice scansione delle vulnerabilità: il sistema in questione viene periodicamente sondato da un dispositivo di scansione, che analizza le risposte (sotto forma di report).

Il report fornisce alcune informazioni, ad esempio quale sistema operativo potrebbe essere in esecuzione su quel dispositivo, quali servizi potrebbero esservi attivi, e possibilmente anche quale versione dei servizi rilevati (il condizionale precedente non è un caso: un penetration tester junior potrebbe infatti essere ingannato da una Honeypot).

I risultati della scansione possono essere incrociati con firme notoriamente errate, come software dannosi o versioni vulnerabili di software o componenti legittimi, producendo report che possono influenzare l’attendibilità del dispositivo in maniera documentata.

Esistono numerosi software, sia Open Source che commerciali, utili per effettuare scansioni di vulnerabilità, tra cui OpenVAS, Nessus, ZAP e Metasploit: progetti in continuo ampliamento, e sebbene nessuno di essi presi singolarmente sia esaustivo, vi fanno affidamento moltissimi professionisti InfoSec, me compreso, così come molte organizzazioni.

Software per la gestione delle configurazioni

Con Gestione delle Configurazioni ci si riferisce al processo di documentazione e censimento mirato di software, sistemi e delle loro configurazioni. Le configurazioni desiderate sono definite come codici o dati, e verificate tramite un RCS (Revision Control System), consentendo di tracciare ed effettuare il rollback dei cambiamenti non previsti o non desiderati.

Sono disponibili da anni diversi software a tal proposito, ad esempio come Chef, Puppet, Ansible e CFEngine.

Software di questo tipo sono fondamentali sia per i server nei datacenter che per tener traccia delle installazioni client, sia in ambienti Cloud che per sistemi On-premises affollati, e spesso il loro utilizzo è anche obbligatorio a causa delle normative di riferimento.

Immaginiamo un’organizzazione che abbia a che fare con centinaia se non migliaia di host tra macchine virtuali, server fisici ed appliance: come facciamo, ad esempio, a tener traccia di tutte le librerie (Open Source e non) installate sui vari host? Delle esatte versioni in produzioni piuttosto che in collaudo, nonché delle loro dipendenze?

Sfruttare i software per la Gestione delle Configurazioni (d’ora in avanti CM) comporta diversi vantaggi in termini di Cybersecurity, ad esempio come la possibilità di aggiornare rapidamente i pacchetti dopo gli annunci di vulnerabilità, o di poter affermare con certezza che nella propria infrastruttura non sono installati i pacchetti vulnerabili segnalati nei più recenti CVE.

Oltre al rigoroso controllo delle modifiche e alla possibilità di fare audit dei pacchetti, i CM possono essere utilizzati anche come agent per le configurazioni dinamiche delle policy.

Se un nodo può ottenere una visione affidabile e attendibile del contesto a cui appartiene, può utilizzarla per calcolare la policy e installarla localmente.

Tuttavia, questa funzionalità al momento è limitata ai datacenter, poiché i sistemi in esso ospitati sono decisamente più statici e prevedibili dei sistemi client.

Ho già citato l’idea di utilizzare un database CM per scopi di Gestione dell’Inventario (d’ora in avanti AM, come Asset Management): è un primo passo verso un sistema AM maturo, e potrà fornire una ricca fonte informativa su tutti gli host e software in esecuzione nell’infrastruttura.

Ci piace pensare che la gestione dell’AM basata sui CM sia un “omaggio” in quanto i CM vengono generalmente sfruttati per lo stuolo degli altri vantaggi che apportano, ma il loro utilizzo come “database d’Inventario” il più delle volte avviene per comodità.

Avere a mente questa visione è importante: i software di CM non sono progettati per agire come sistemi AM, ma per essere usati come sistemi per gestire configurazioni! Usarli come tali porta alcune rogne iniziali, ma a mio modesto avviso è meglio realizzare una rete ZTS sfruttando più tecnologie combinate piuttosto che non avere un’esatta visibilità degli apparati e delle configurazioni che si hanno nei datacenter in cui si opera.

Alcuni software di CM memorizzano centralmente i dati generati dai loro agent. In genere, questi archivi di dati sono interrogabili attraverso delle query, il che apre molte opportunità per le reti ZTS. Ad esempio, l’agent può eseguire una ricerca per recuperare l’indirizzo IP di tutti i server Web nel datacenter “x”, utilizzando poi i risultati per configurare via SSH le policy di un firewall.

I controlli e la generazione di report sono notevolmente migliorabili attraverso un AM, e questo vale non solo per gli host nei data center, ma anche per i client.

Memorizzando i dati dell’agent e rendendoli ricercabili sarà così possibile assicurarsi di poter modificare il codice del CM per aggiornare quel certo pacchetto vulnerabile, e che il pacchetto sarà effettivamente aggiornato là dove lo ha imposto il sistemista.

Chiarito questo aspetto, possiamo sfruttare la ricchezza dei dati forniti dagli agent dei CM e dai sistemi di AM. Utilizzando Chef, ad esempio, possiamo calcolare il punteggio di affidabilità e schedulare criteri in base a più di 1.500 attributi host.

Ecco un esempio che illustra il tipo di informazioni raccolte e archiviate dal suo agent:

languages:

 c:

  gcc:

   description: gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)

   version: 4.8.4

java:

 hotspot:

  build: 24.71-b01, mixed mode

  name: Java HotSpot(TM) 64-Bit Server VM

runtime:

 build: 1.7.0_71-b14

 name: Java(TM) SE Runtime Environment

version: 1.7.0_71

perl:

… <SNIP> …

dmi:

 bios:

  address: 0xE8000

  all_records:

                      Address: 0xE8000

                     BIOS Revision: 4.2

                     ROM Size: 64 kB

                     Release Date: 12/03/2014

                     Runtime Size: 96 kB

                     Vendor: Xen

                     application_identifier: BIOS Information

chassis:

 all_records:

                     Asset Tag: Not Specified

                     Boot-up State: Safe

… <SNIP> …

fqdn: dmzwarelab.local

hostname: dmzwarelab

idletime: 2 days 09 hours 48 minutes 37 seconds

idletime_seconds: 208117

init_package: init

ipaddress: 192.168.1.1

kernel:

machine: x86_64

modules:

ablk_helper:

refcount: 6

size: 13597

… <SNIP> …

 network:

 default_gateway: 192.168.1.254

 default_interface: eth0

 interfaces:

                     eth0:

                      addresses:

                       192.168.1.1:

                                         broadcast: 192.168.1.255

                                         family: inet

                                         netmask: 255.255.255.0

                                         prefixlen: 24

                                         scope: Global

                       08:6B:C5:63:D7:AD:

                                         family: lladdr

                      arp:

                                         192.168.1.2: fe:ff:ff:ff:ff:ff

                                         192.168.1.3: fe:ff:ff:ff:ff:ff

                                         192.168.1.254: fe:ff:ff:ff:ff:ff

    encapsulation: Ethernet

Un altro fattore da rammentare quando si utilizzano i sistemi di CM nel Piano di controllo ZTS è che la stragrande maggioranza dei dati disponibili per i sistemi di CM sono auto-alimentati, il che significa che un host compromesso potrebbe potenzialmente rappresentare sé stesso in modo errato o ingannevole.

Ciò può portare alla compromissione della rete ZTS se questi aspetti non vengono presi in considerazione fin dalla fase di progettazione.

Ripensando alla gestione della fiducia, il sistema fidato in questo caso è il fornitore. Che si tratti di un essere umano o di un sistema automatizzato, è nella posizione più adatta per affermare gli aspetti critici di un dispositivo, che includono:

• tipo di device;
• ruolo;
• indirizzo IP nel datacenter;
• chiave pubblica;

Questi attributi sono considerati critici poiché vengono spesso utilizzati per prendere decisioni di Autorizzazione e Autenticazione. Se ad esempio un attacker può aggiornare il ruolo del dispositivo, forse può costringere la rete a esporre i servizi (daemon) protetti: per questo motivo è fondamentale limitare l’accesso in scrittura a questi attributi.

Utilizzo dei dati del dispositivo per l’autorizzazione dell’utente

Il modello Zero Trust impone l’Autenticazione e l’Autorizzazione sia del dispositivo che dell’utente/applicazione. Poiché l’Autenticazione del dispositivo in genere viene prima dell’Autenticazione dell’utente, deve essere eseguita senza informazioni ottenute tramite l’Autenticazione dell’utente.

Questo non è il caso dell’Autenticazione dell’utente: quando si verifica, l’Autenticazione del dispositivo è già riuscita, e la rete è a conoscenza dell’Identità del dispositivo. Questo scenario può essere sfruttato per tutti i tipi di utili conoscenze contestuali, consentendoci di eseguire un’Autenticazione dell’utente molto più forte di quanto fosse possibile in precedenza.

Una delle ricerche più comuni che possiamo fare è verificare se ci aspettavamo il tal utente, dato il tal tipo di dispositivo o luogo del problema. Ad esempio, è improbabile che noi si veda le credenziali di un tecnico utilizzate da un dispositivo mobile che è stato rilasciato ad HR.

Pertanto, mentre il dipendente di HR può accedere liberamente a una particolare risorsa utilizzando le proprie credenziali, i tentativi di Autenticazione dell’utente utilizzando altre credenziali potrebbero essere bloccati.

Un altro buon segnale è la frequenza di Autenticazione dell’utente. Se non vediamo un utente accedere da uno dei suoi dispositivi da più di un anno e all’improvviso c’è una richiesta da quel dispositivo che fornisce le credenziali dell’utente, è giusto divenire un po’ scettici.

Potrebbe essere stato rubato? Naturalmente ci sono anche buone possibilità che la richiesta sia del tutto legittima. In un caso come questo potremmo abbassare il punteggio di affidabilità per indicare che le cose sono un po’ sospette: il punteggio più basso può quindi manifestarsi in molti modi, come ad esempio essere trustati a sufficienza per poter accedere a un server ftp interno, ma non abbastanza da poter accedere ai sistemi finanziari.

Prendere decisioni come questa è una parte essenziale delle architetture ZTS, e sottolinea l’importanza di un solido sistema di AM nonché di software di CM. Mentre la gestione dell’Inventario è strettamente necessaria per motivi di Autenticazione del dispositivo, il vantaggio contestuale dato all’Autenticazione dell’utente è inestimabile.

Segnali di attendibilità

Con il passar del tempo la probabilità che un dispositivo venga compromesso aumenta notevolmente. Le best practices di cyber security degli endpoint mirano a ridurre il rischio associato all’utilizzo a lunga durata dei dispositivi, tuttavia, queste pratiche sono tutt’altro che esaustive.

L’imaging di un dispositivo garantisce che il contenuto del disco rigido corrisponda a un bene noto: sebbene non sia efficace contro alcuni attacchi di più basso livello, fornisce una garanzia di affidabilità (di “trust”) ragionevolmente robusta.

Nei momenti immediatamente successivi al ripristino dell’immagine esiste un’ampia quantità di trust nel dispositivo, poiché solo l’hardware o il sistema di ripristino stesso potrebbero (se compromessi) contaminare il processo.

Nel corso del tempo, tuttavia, tale livello di trust svanisce man mano che il sistema subisce un’esposizione prolungata.

I modelli di Autenticazione del dispositivo, simili ai modelli di Autenticazione dell’utente, sono fondamentali per comprendere il rischio e fungono da proxy per il filtraggio comportamentale. I dispositivi che non vengono analizzati da tempo sono più sospetti di quelli che vanno e vengono frequentemente.

Forse sospetti non è la parola più adatta, ma certamente sono insoliti (pensiamo al concetto di delta in matematica: di quanto delta si discosta il comportamento del dispositivo x dalla classe di dispositivi a cui appartiene?).

La richiesta in questione può anche essere legata a una risorsa, ed è più prudente considerare insieme il dispositivo e la risorsa in questo contesto.

Ad esempio, un dispositivo vecchio di mesi che richiede l’accesso a una nuova risorsa è più insolito di una richiesta a una risorsa a cui si accede più o meno settimanalmente già da un po’. Ciò significa che i “primi” tentativi di accesso a una particolare risorsa sono visti con più scetticismo rispetto ai tentativi successivi.

Allo stesso modo, la frequenza può essere analizzata per capire se una risorsa o un dispositivo possono essere “indiziati”: una richiesta da un dispositivo che ha effettuato 100 richieste nell’ultimo giorno, ma solo 104 nell’ultimo mese, è sicuramente più sospetta di una con 0 richieste nell’ultimo giorno e 4 nell’ultimo mese.

Nel modello ZTS, sebbene la posizione in rete sia qualcosa su cui in genere cerchiamo di non prendere decisioni drastiche, in molti casi è in grado, comunque, di fornire segnali di trust. Uno di questi casi potrebbe essere un improvviso cambio di posizione: dal momento che stiamo parlando di Autenticazione del dispositivo, possiamo impostare alcune aspettative ragionevoli sul modo in cui il dispositivo si muove.

Ad esempio, un tentativo di Autenticazione verso il servizio Samba nel nostro NAS da un indirizzo IP in Russia potrebbe essere sospetto se abbiamo configurato lo stesso dispositivo nell’ufficio in Italia solo un paio d’ore prima (e non abbiamo né clienti né commerciali o consulenti in Russia nel momento in cui viene tracciato l’evento).

ZTS mira ad eliminare le posizioni di vantaggio all’interno della rete, quindi l’utilizzo della posizione della rete per determinare il diritto di accesso può essere considerato un po’ contraddittorio: detto questo, è importante che questa considerazione non sia duplice. Si dovrebbero cercare modelli nelle posizioni e non prendere mai una decisione assoluta basata esclusivamente sulla posizione.

Per i dispositivi connessi a reti di proprietà dell’ISP esiste l’opportunità di misurare i modelli di comunicazione per sviluppare una norma, una sorta di “template comportamentale”. I delta rispetto a questa norma saranno considerati sospetti, e potranno influire sulla percentuale di trust del sistema in tale dispositivo.

Gli IDS e l’analisi del traffico di rete possono rilevare rapidamente le intrusioni abusive, e prendere decisioni di Autorizzazione tenendo conto dei relativi allarmi e warning è imprescindibile: un esempio potrebbe essere la chiusura dell’accesso a un database da un particolare web server poiché magari quel web server ha iniziato a eseguire query DNS per i provider di hosting in un altro continente. Lo stesso vale per i dispositivi client.

Consideriamo un desktop che non ha mai avviato una connessione SSH prima d’oggi, ma che ora effettua molteplici connessioni SSH verso host su Internet. Non è azzardato affermare che questo delta di comportamento (un delta dalla norma) è sospetto e dovrebbe far sì che il dispositivo venga considerato meno affidabile di quanto non lo fosse in precedenza.

Conclusioni

In questo articolo ho cercato di sintetizzare alcune riflessioni in merito a come una rete ZTS possa o meno fidarsi di un dispositivo.

È un problema non banale, quindi è doveroso applicare molte tecnologie e approcci analitici congiunti per garantire che la fiducia in un certo dispositivo venga assegnata e mantenuta in maniera affidabile.

Abbiamo iniziato discutendo di come la fiducia (il livello di “trust”) venga iniettata in un dispositivo già dai tecnici di primo livello.

Per sistemi relativamente statici, possiamo pensare di coinvolgere una persona nel fornire le credenziali critiche, ma in un’infrastruttura dinamica, tale processo deve essere delegato.

Queste credenziali sono incredibilmente preziose, quindi abbiamo accennato a come gestirle in Sicurezza. I dispositivi presto o tardi dovranno operare in rete, quindi capire come si autenticano è fondamentale.

Abbiamo parlato di diverse tecnologie, come X.509 e TPM, che possono essere utilizzate per autenticare un dispositivo in una rete ZTS.

L’utilizzo di queste tecnologie combinate con sistemi AM e CM costituisce l’avamposto delle fonti di Sicurezza con cui realizzare i dovuti controlli e assegnare i punteggi che iniettano fiducia nei dispositivi. La fiducia (di nuovo, la percentuale di “trust”) è fugace e si degrada nel tempo, quindi, abbiamo riflettuto sui meccanismi per rinnovarla.

Inoltre, abbiamo discusso dei numerosi segnali che possono essere continuamente esaminati per valutare l’affidabilità di un dispositivo nel tempo. Forse la lezione più importante è che in ambienti ZTS un dispositivo inizia la sua vita in rete in uno stato attendibile, e da lì non fa che peggiorare: la velocità con cui la sua fiducia diminuisce nel tempo costituisce il parametro primario con cui dovrebbe essere tenuto sotto controllo.

Se hai avuto la curiosità e la pazienza di giungere fin qui con la lettura, la domanda/provocazione che ti rivolgo è: come effettui/effettuano il trust dei dispositivi nell’azienda in cui lavori? Vengono rispettati questi principi? Hai/avete mai effettuato dei test per verificare se effettivamente ciò che è stato indicato nero su bianco nelle policy relativamente al livello di trust dei dispositivi corrisponde empiricamente a verità?

Se così non fosse, hai/avete un problema da risolvere e anche al più presto.