Zero Trust Security: come gestire e garantire la fiducia delle applicazioni

Nell’ambito della Zero Trust Security (ZTS) un dispositivo fidato (“trusted”) costituisce uno dei requisiti fondamentali per potersi fidare anche del codice. Tuttavia, anche in presenza di un ambiente di esecuzione certificato, c’è ancora molto lavoro da fare per rendere sicuro il codice in esecuzione su di un certo dispositivo.

Ergo, potersi fidare dei dispositivi è solo uno dei requisiti: bisognerebbe, infatti, anche potersi fidare del codice sviluppato dai programmatori (fornitori esterni piuttosto che dipendenti della software house in questione) di quel certo software (sito, applicazione o firmware/app operativo all’interno di un dispositivo IoT).

Con l’obiettivo di garantire l’integrità di un’applicazione in esecuzione, occorre quindi trovare dei metodi per estendere effettivamente questa fiducia dal codice a riposo (binario non in esecuzione) fino alla sua effettiva esecuzione a runtime.

In un mondo ideale, per trustare il codice è necessario che:

1. gli sviluppatori che lo hanno programmato siano loro stessi fidati;
2. il codice sia stato realizzato rispettando minuziosamente i principi del Secure Coding;
3. le applicazioni attendibili siano distribuite in sicurezza nell’infrastruttura ICT (oppure OT se trattasi di un contesto industriale);
4. le applicazioni siano continuamente monitorate per individuare eventuali tentativi di compromissione (attraverso attacchi informatici interni o esterni)del codice in esecuzione.

Questo articolo illustra alcuni approcci per gestire in sicurezza ciascuno di questi punti, ponendo particolare attenzione all’ereditarietà della fiducia (“trust”) dai team DevOps fino all’applicazione in produzione.

Comprendere la pipeline dello sviluppo software

Le fasi di creazione, delivery ed esecuzione del codice all’interno di un sistema informatico costituiscono una catena di eventi estremamente delicata.

Queste fasi rappresentano un obiettivo ambito per gli attacker grazie alla loro capacità di ottenere un accesso privilegiato. Da anni sono documentati vettori di attacco per ogni fase della CI/CD (integrazione e deployment continui), e le manipolazioni nella catena possono essere molto insidiose da rilevare.

Pertanto, occorre ingegnarsi per garantire che ogni anello di questa catena venga protetto in modo tale da rendere rilevabili i tentativi di sofisticazione:

Una pipeline CI/CD dipende sia dall’affidabilità degli sviluppatori che creano il codice sorgente e (come nel caso dei DevOps) configurano i sistemi, sia dalla sicurezza informatica intrinseca dei componenti usati nella pipeline.

Questo approccio è simile alla sicurezza delle catene di approvvigionamento (“Supply Chain Security”), ovvero agli sforzi collettivi di governi e organizzazioni per migliorare la sicurezza (anche informatica) dei fornitori e quindi delle forniture.

1. Esempio 1: nel 2007 il governo israeliano ha condotto un attacco aereo contro un presunto impianto nucleare in Siria. Uno dei tanti misteri che circondano questo attacco è l’improvviso guasto dei sistemi radar siriani, che all’epoca fornivano copertura contro gli israeliani: oggi si ritiene che il guasto di quei sistemi radar, che si supponeva fossero all’avanguardia, sia attribuibile a un kill switch hardwarenascosto in un chip commerciale utilizzato nell’apparecchiatura radar. Sebbene non siano mai stati completamente verificati, episodi come questo evidenziano l’importanza di catene di approvvigionamento sicure, che si tratti di hardware o software.
2. Esempio 2: l’azienda SolarWinds aveva messo in piedi processi per svolgere le build software in modo (apparentemente) sicuro, e controlli sull’integrità degli aggiornamenti. Tuttavia, questi controlli sono stati violati, e per parecchi mesi SolarWinds ha inconsapevolmente distribuito un aggiornamento malevolo a più di 18.000 organizzazioni, di cui almeno 100 sono rimaste infettate ed in breve tempo compromesse.

Per realizzare una catena di distribuzione software sicura (d’ora in avanti indicato con CI/CD nell’articolo), ogni fase della catena deve essere completamente verificabile attraverso una convalida crittografica da applicare in ogni punto critico. In generale, questi passaggi possono essere suddivisi in quattro distinte fasi:

1. raccolta e trusting del codice sorgente;
2. build;
3. distribuzione;
4. esecuzione.

Trusting del codice sorgente

Il codice sorgente è il primo passo per realizzare qualunque software, ma è molto rischioso fidarsi del codice sorgente scritto da qualcuno che non sia fidato.

Anche con un controllo capillare del codice sorgente è ancora possibile che uno sviluppatore in malafede codifichi appositamente una vulnerabilità, o anneghi volutamente una backdoor nel codice (all’estero esiste addirittura una competizione di programmazione dedicata a tali scopi).

Sebbene anche gli sviluppatori in buona fede possano inavvertitamente aggiungere punti deboli a un’applicazione, una rete Zero Trust si concentra sull’identificazione dei potenziali usi dannosi piuttosto che sulla rimozione della fiducia da tali utenti.

Mettendo un attimo da parte il dilemma dello sviluppatore fidato, cerchiamo di affrontare il problema dell’archiviazione e distribuzione sicura del codice sorgente stesso.

In genere, il codice sorgente viene archiviato in un repository centralizzato con il quale gli sviluppatori interagiscono più o meno periodicamente. Anche questi repository devono essere sottoposti ad un rigoroso controllo, in particolare se vengono utilizzati direttamente dai sistemi che creano/compilano il codice sorgente in questione.

Applicare i tradizionali approcci di sicurezza informatica quando si tratta di proteggere un repository software costituisce ancora una best practice, ma questo non ci impedisce di aggiungere funzionalità di controllo e monitoraggio più avanzate.

Tra queste funzionalità avanzate, una priorità dovrebbe essere assegnata al principio dell’accesso minimo, in base al quale agli utenti andrebbe concesso l’accesso al solo repository necessario per completare le attività da svolgere.

Nella realtà, tuttavia, di solito questo scenario si palesa come un accesso in scrittura fortemente limitato. Sebbene questo approccio sia ancora consigliabile, la storia si è evoluta con l’introduzione dei controlli sul codice sorgente distribuito.

Poiché in questi casi i repository del codice possono risiede in più luoghi, non è possibile proteggere un’unica entità centralizzata: in questa circostanza, tuttavia, rimane centralizzato il sistema che memorizza il codice da cui legge il sistema di compilazione.

In questo caso è auspicabile tutelare questo sistema con mezzi tradizionali; tuttavia, il problema diventa più complesso poiché il codice sorgente può accedere al repository distribuito in diversi modi.

La conseguenza logica, quindi, è che la sola protezione del repository dei sorgenti di build non è sufficiente.

Molti sistemi di controllo delle versioni (VCS), in particolare quelli distribuiti, archiviano la cronologia dei codici sorgenti applicando anche tecniche crittografiche. Questo approccio, chiamato content addressable storage, utilizza l’hash del contenuto archiviato come identificatore di quell’oggetto in un database, piuttosto che la sua posizione o le sue coordinate.

È possibile vedere come un file sorgente venga sottoposto ad hashing e archiviato in un database di questo tipo, garantendo così che qualsiasi modifica al file generi un nuovo hash.

Questa proprietà implica che i file verranno archiviati in modo immutabile: applicando quindi funzioni hash quantum-safe risulta estremamente complicato modificare il contenuto dei file archiviati senza essere scoperti.

Alcuni VCS migliorano questo meccanismo di archiviazione memorizzando la cronologia stessa come oggetto nel database. Git, il più popolare tra i sistemi VCS distribuiti, memorizza la cronologia dei commit nel repository sfruttando un grafico aciclico diretto (DAG): i commit vengono tracciati come oggetti nel database, e vengono memorizzati dettagli come l’ora del commit, l’autore e gli identificatori dei commit precedenti.

Memorizzando gli hash dei commit antenati su ciascun commit stesso, viene formato un albero di Merkle che consente di verificare crittograficamente se la catena dei commit è stata o meno alterata.

Git rende difficili le modifiche abusive poiché gli oggetti vengono referenziati utilizzando un hash del loro contenuto.

Se un commit nel DAG dovesse essere modificato in maniera fraudolenta, questa condizione influenzerà tutti i commit discendenti nel grafico, modificando il contenuto di ciascun commit e, per estensione, il suo identificatore.

Con la cronologia della fonte distribuita agli sviluppatori, il sistema dispone di un’altra vantaggiosa proprietà: è impossibile modificare la cronologia evitando che gli altri sviluppatori se ne accorgano.

Conservare il DAG in questo modo ci fornisce una cronostoria dei commit a prova di manomissione, tuttavia, questa archiviazione non garantisce che i nuovi commit nella cronologia siano autorizzati e autentici.

Immaginiamo per un momento che uno sviluppatore fidato venga convinto a inserire una modifica malevola (una backdoor, un bug importante o una reverse shell ad esempio) nel proprio repository locale prima di inserirlo nel repository ufficiale: questo commit sarà depositato nel repository centralizzato subito dopo il push effettuato dallo sviluppatore “affidabile”.

Ancor più preoccupante, i metadati di paternità sono semplicemente testo: un committente malintenzionato può inserire tutti i dettagli che desidera in quel campo (un fatto che è stato utilizzato in modo divertente per far sembrare che i commit siano stati autorizzati da Linus Torvalds su GitHub).

Per proteggerci da questo vettore di attacco, Git ha la possibilità di firmare commit e tag utilizzando le chiavi GPG degli sviluppatori. I tag (che puntano al commit principale in una determinata cronologia) possono essere firmati utilizzando una chiave GPG per garantire l’autenticità di una certa versione del software.

I commit firmati consentono di fare un ulteriore passo avanti, ossia autenticare l’intera cronologia Git rendendo impossibile per un attacker impersonare un altro sviluppatore senza prima essersi appropriato della sua chiave GPG.

Il codice sorgente firmato offre chiaramente vantaggi significativi, e dovrebbe diventare una best practice da applicare senza remore: fornisce una solida autenticazione del codice non solo per gli sviluppatori, ma anche per gli host.

Questo approccio è fondamentale se nella tua organizzazione i sistemi CI/CD distribuiscono il codice in autonomia. Una cronologia firmata consente ai sistemi di compilazione di autenticare crittograficamente il codice prima di compilarlo per la distribuzione.

I commit firmati del codice sorgente ci consentono di autenticare lo sviluppatore che desidera inviare il codice, ma non garantiscono che il codice stesso sia immune da vulnerabilità o contenga malware.

Per mitigare questo rischio, le organizzazione più attente alla cyber security implementano un processo di revisione del codice (o Code Review). Durante la fase di Code Review, tutti i contributi devono essere approvati da uno o più sviluppatori aggiuntivi con competenze tecniche di Secure Coding: questo processo meticoloso migliora drasticamente non solo la qualità del software, ma riduce anche la velocità e la possibilità con cui vengono abitualmente introdotte le vulnerabilità, siano esse intenzionali o accidentali.

L’affidabilità dei bild server (o dei sistemi di compilazione)

I server per le Build sono spesso presi di mira da minacce persistenti (APT), e per una buona ragione. Sono spesso configurati e dotati di un accesso elevato, e rilasciano codice che viene eseguito direttamente in produzione.

Rilevare gli artefatti che sono stati compromessi durante la fase di Build può essere molto complicato, quindi, risulta estremamente importante applicare solide protezioni a questi server.

Sono almeno tre gli aspetti generali da cui partire per riflettere in merito alla possibilità di fidarsi o non fidarsi di un certo sistema di compilazione:

1. Il codice sorgente compilato corrisponde fedelmente al codice che gli sviluppatori intendevano creare?
2. Il processo di creazione/configurazione è andato effettivamente come previsto?
3. La Build è stata eseguita fedelmente, senza manipolazioni?

I sistemi utilizzabili per realizzare le Build possono ingerire codice sorgente firmato restituendo in output codice compilato firmato, ma le funzioni applicate nel mezzo (ad esempio, la Build stessa) generalmente non sono protette crittograficamente: ed è qui che si nasconde uno dei vettori di attacco più ambiti.

Senza dei processi di validazione precauzionali, una sofisticazione di questo tipo può essere difficile o impossibile da rilevare.

Ad esempio, immaginiamo che venga compromesso un sistema CI/CD in grado di elaborare codice sorgente C++, di compilare i relativi .exe nonché firmarli digitalmente, e che il medesimo codice venga quindi distribuito ed eseguito in produzione: i sistemi in produzione potranno verificare se il file binario è stato effettivamente firmato e da chi, ma non avranno modo di sapere se durante il processo di Build il sistema CI/CD è stato abusivamente indotto a compilare anche del codice malevolo.

In questo scenario, un sistema apparentemente sicuro potrebbe far eseguire del codice malevolo in produzione senza essere rilevato… e ancor peggio, i consumatori verrebbero indotti a pensare che il risultato sia affidabile!

A causa della delicata architettura dei meccanismi di elaborazione delle Build, l’esternalizzazione di questo servizio (e quindi delle responsabilità: chi risarcisce chi in caso di un attacco informatico alla catena CI/CD andato a buon fine?) dovrebbe essere attentamente valutata.

Ad esempio, le Build riproducibili possono indubbiamente contribuire all’identificazione di scenari compromessi, ma non possono sempre impedire la distribuzione di codice malevolo.

È davvero qualcosa che desideri che un fornitore di terze parti faccia per te? Quanto ti fidi di loro? Anche qui, la cybersecurity Posture dei tuoi fornitori dovrebbe essere attentamente valutata rispetto alla possibilità che la tua organizzazione non divenga (o ancor peggio non sia già) un obiettivo di alto livello per qualche tuo competitor.

Se pensiamo alla compilazione come ad un’operazione sempre affidabile, è chiaro che per produrre un output affidabile dobbiamo necessariamente fidarci dell’input di tale operazione.

Iniziamo riflettendo sul trusting dell’input del sistema di compilazione: ho discusso in precedenza i meccanismi che occorre attuare per potersi fidare dei sistemi di controllo del codice sorgente (VCS).

Il sistema di compilazione, in quanto consumatore del VCS, è responsabile della convalida dell’affidabilità della fonte. È necessario accedere al VCS tramite un canale autenticato, comunemente tramite protocollo TLS (ma le aziende più attente usano la variante mTLS). Inoltre, per ulteriore garanzia di sicurezza, i tag e/o i commit dovrebbero essere firmati digitalmente, e il sistema di compilazione dovrebbe convalidare tali firme digitali, o catena di firme, prima di avviare una compilazione.

La configurazione della Build è un altro input importante per il sistema di compilazione: attaccare la configurazione della Build potrebbe consentire a un attacker di reindirizzare il sistema di Build verso una libreria dannosa.

Anche i flag di ottimizzazione (apparentemente sicuri) potrebbero divenire dannosi se annegati nel codice critico per la sicurezza informatica, là dove il codice di mitigazione degli attacchi temporali può essere accidentalmente ottimizzato.

Mettere questa configurazione sotto il controllo del codice sorgente, dove può essere modificata e attestata tramite commit firmati digitalmente, contribuisce a garantire che anche la configurazione stessa della build divenga un input affidabile.

Con l’input sufficientemente protetto, possiamo adesso rivolgere la nostra attenzione all’output del processo di compilazione: il sistema di compilazione deve firmare digitalmente gli artefatti generati in modo che i sistemi a valle possano convalidarne l’autenticità.

I sistemi di build generano anche hash degli artefatti di build per proteggerli da modifiche in buona fede piuttosto che da veri e propri tentativi di modifiche malevole a posteriori (binary patching).

Proteggere gli artefatti e gli hash di build, e quindi distribuirli ai consumatori a valle, completa l’affidabilità del sistema di build.

Processi di build riproducibili

Al momento le build riproducibili costituiscono uno dei migliori strumenti a disposizione per proteggersi dai tentativi di sofisticazione della pipeline di compilazione.

In breve, il software che supporta build riproducibili viene compilato in maniera deterministica, garantendo che il codice binario risultante sia esattamente identico per un determinato codice sorgente, indipendentemente da chi lo ha creato: questa è una proprietà estremamente importante poiché consente a più parti di esaminare il codice sorgente e riprodurre build identiche, ottenendo così la certezza che il processo di build utilizzato per generare un particolare binario non sia stato alterato.

Questo può essere fatto in diversi modi, ma generalmente implica un processo di compilazione codificato che consenta agli sviluppatori di impostare il proprio ambiente di compilazione per produrre file binari che corrisponderanno alle versioni distribuite bit per bit.

Con le build riproducibili è possibile “analizzare l’output di un sistema CI/CD” e confrontare il suo output con i risultati compilati localmente: in questo modo è facile rilevare le interferenze dannose o eventuali modifiche malevoli apportate al codice durante il processo di creazione. Se combinato con il codice sorgente firmato, stiamo edificando un processo abbastanza robusto in grado di autenticare sia il codice sorgente che i file binari da esso prodotto.

Le build immutabili sono fondamentali per garantire la sicurezza di un sistema di build e del suo rilascio. Senza di esse è possibile sostituire una versione nota e valida, aprendo la porta ad attacchi che prendono di mira l’artefatto di build sottostante.

Ciò consentirebbe a un utente malintenzionato di mascherare una versione contraffatta come fosse una versione autentica.

Per questo motivo, gli artefatti generati dai sistemi di compilazione dovrebbero essere configurati con la policy Write Once Read Many. Dato il requisito di immutabilità degli artefatti, sorge un conflitto quasi automatico con il controllo delle versioni: molti progetti preferiscono utilizzare numeri di versione significativi (ad esempio, il controllo semantico delle versioni) nelle loro versioni per comunicare il potenziale impatto ai consumatori a valle con un aggiornamento del loro software.

Questo desiderio di attribuire un significato al numero di versione può essere difficile da incorporare in un sistema di compilazione che debba garantire che ogni versione sia immutabile. Ad esempio, quando si lavora verso una versione principale, un progetto potrebbe avere una build configurata in modo errato che farà sì che il sistema di compilazione produrrà un output errato.

I manutentori, allora, si troveranno di fronte a una scelta: potrebbero ripubblicare la versione avvalendosi di un upgrade a livello di patch, oppure potrebbero decidere di infrangere le regole e ripubblicare la stessa versione utilizzando un nuovo artefatto di build.

Molti progetti scelgono quest’ultima opzione, preferendo il vantaggio di una storia di marketing più chiara rispetto ad una o più rollback compliant.

Da questo esempio risulta lapalissiano che in entrambi i casi verranno prodotti due diversi artefatti di build, e il numero di versione associato all’artefatto costituirà una scelta separata per il progetto. Pertanto, quando si configura un sistema di build, è opportuno che il sistema di compilazione produca versioni immutabili indipendenti dalla versione comunicata pubblicamente: un sistema successivo (il sistema di distribuzione) potrà gestire la mappatura delle versioni di rilascio per creare le versioni degli artefatti.

Questo approccio consente di mantenere immutabili gli artefatti di build senza sacrificarne l’usabilità, e senza introdurre rischiose pratiche per la sicurezza informatica.

A valle del processo di Build, il processo di selezione degli artefatti da consegnare ai clienti è definito distribuzione: il sistema di compilazione genera numerosi artefatti, alcuni dei quali sono destinati al consumo a valle, pertanto, occorre garantire che il sistema di distribuzione mantenga il controllo su quali artefatti verranno consegnati.

Viceversa, la promozione è l’atto di designare un artefatto di build come versione autorevole senza modificare il contenuto dell’artefatto stesso.

Questo atto dovrebbe essere immutabile: una volta assegnata e rilasciata una versione, non deve poter essere modificabile. Invece, un nuovo artefatto dovrà essere creato e rilasciato con un numero di versione incrementale sequenziale.

Questo vincolo presenta una sorta di problema dell’uovo e della gallina: il software in genere include un modo per segnalare il numero di versione all’utente, ma se il numero di versione non viene assegnato fino a una fase successiva del processo di creazione, come si possono aggiungere le informazioni sulla versione senza modificare l’artefatto di creazione?

Un approccio ingenuo è quello di modificare leggermente l’artefatto durante il processo di promozione, ad esempio, memorizzando il numero di versione in una posizione banalmente modificata nell’artefatto di compilazione: questo approccio, tuttavia, non è quello preferibile.

Gli addetti al rilascio, infatti, dovrebbero effettuare una chiara separazione tra il numero di versione rilasciato pubblicamente e il numero di build, che è un componente aggiuntivo delle informazioni sul rilascio.

Con questo modello, verranno prodotti molti artefatti di build che utilizzeranno la stessa versione del rilascio pubblico, ma ogni build sarà contrassegnata con un numero di build univoco.

In quest’ottica, il rilascio di quella specifica versione consisterà nello scegliere l’artefatto di build che dovrà essere firmato digitalmente e distribuito. Una volta rilasciata tale versione, tutte le nuove build dovranno essere configurate per utilizzare il numero di versione di destinazione successivo.

Naturalmente, questa promozione deve essere comunicata al cliente in modo che possa dimostrare di essere in possesso dell’effettiva build promossa, e non di una build intermediaria o potenzialmente difettosa.

Esistono diversi modi per farlo, ed è in gran parte un problema risolto: una soluzione consiste nel firmare digitalmente gli artefatti promossi con una chiave di solo rilascio, comunicandola così agli utenti che dispongono di una build promossa.

Un modo alternativo è pubblicare un manifesto firmato digitalmente, delineando le versioni rilasciate e i relativi hash. Molti popolari sistemi di distribuzione dei pacchetti (come apt ad esempio) utilizzano questo metodo per convalidare le build ottenute dai loro sistemi di distribuzione.

Distribuzione in sicurezza

La distribuzione del software è paragonabile alla distribuzione dell’elettricità, scenario in cui l’elettricità viene generata da una fonte centralizzata e trasportata su di una rete di distribuzione per essere consegnata ad un’ampia fetta di consumatori.

A differenza dell’elettricità, tuttavia, l’integrità del software prodotto deve essere protetta mentre transita attraverso il sistema di distribuzione, consentendo al consumatore di validarne autonomamente l’integrità.

Esistono numerosi sistemi di distribuzione e gestione dei pacchetti, e quasi tutti implementano protezioni nel processo di distribuzione consentendo agli utenti di convalidare l’autenticità dei pacchetti ricevuti tramite essi.

Di seguito farò riferimento al diffuso software di gestione dei pacchetti APT (Advanced Packaging Tool) come esempio per mostrare come determinati concetti vengano effettivamente implementati nella vita reale, sebbene sia importante tener presente che ci sono molte altre opzioni a nostra disposizione: APT è semplicemente una tre le più popolari.

I principali meccanismi di sicurezza utilizzati per garantire l’Integrità e l’Autenticità nei sistemi di distribuzione del software sono due: l’hashing e le firme digitali. L’hashing di una versione software comporta l’elaborazione e la distribuzione di un hash che l’utente potrà ricalcolare e convalidare per avere garanzia che il binario non sia stato modificato da quando ha lasciato le mani dello sviluppatore.

La firma digitale di una versione software implica che l’autore crittografi l’hash della versione con la propria chiave privata, consentendo agli utenti finali di verificare che il software è stato rilasciato da una controparte autorizzata. Per comprendere meglio come questi metodi possono essere applicati in un sistema di distribuzione, è utile osservare la struttura e la sicurezza di un repository APT.

Un repository APT contiene tre tipi di file: un file Release, un file Packages e i pacchetti stessi. Il file dei pacchetti funge da indice per tutti i pacchetti nel repository: memorizza un po’ di metadati su ogni pacchetto contenuto nel repository, come nomi di file, descrizioni e checksum. Il checksum di questo indice viene utilizzato per convalidare l’integrità del pacchetto scaricato prima che venga installato.

Ciò ne garantisce l’integrità, assicurandoci che i contenuti non siano stati cambiati al volo: tuttavia, nella maggior parte dei casi è efficace solo contro l’alterazione hardware, poiché un attacker potrebbe semplicemente modificare gli hash dell’indice se l’obiettivo è fornire software modificato.

È qui che entra in gioco il file Release: contiene metadati sul repository stesso (al contrario del file Packages, che memorizza i metadati sui pacchetti contenuti al suo interno). Include dettagli come il nome e la versione della distribuzione del sistema operativo a cui è destinato il repository, un checksum del file Packages, consentendo all’utente di convalidare l’integrità dell’indice, che a sua volta può convalidare l’integrità dei pacchetti che scarichiamo.

È fantastico, tranne per il fatto che un attacker potrebbe comunque modificare il file Release con l’hash aggiornato del file Packages.

Ecco, quindi, la necessità delle firme crittografiche.

Un manutentore autorizzato firma il file del rilascio, che contiene un hash dell’indice dei Package, che a sua volta contiene gli hash dei pacchetti stessi.

Una firma digitale garantisce non solo l’integrità del contenuto del file firmato (poiché nella firma è incluso un hash), ma anche l’autenticità, poiché la decifrazione riuscita della firma dimostra che la parte che l’ha generata era in possesso della chiave privata.

Utilizzando questo principio, il manutentore del repository del software firma il file Release con una chiave privata, della quale esiste una corrispondente chiave pubblica nota e distribuita.

Ogni volta che il repository viene aggiornato, gli hash dei file del pacchetto vengono aggiornati nell’indice, e l’hash finale dell’indice viene aggiornato nel file Release, che verrà quindi firmato.

Questa catena di hash, la cui radice è firmata, offre all’utente la possibilità di verificare l’Autenticità del software che sta per installare: nell’ipotesi in cui non si riesca a firmare una versione del software, è essenziale ricorrere alle pratiche di sicurezza standard.

Occorre assicurarsi che tutte le comunicazioni siano reciprocamente autenticate, ovvero il traffico di rete verso, da e tra qualsiasi repository di distribuzione. Inoltre, occorre garantire che lo storage su cui poggia il repository sia adeguatamente protetto e monitorato, sia esso su Microsoft Azure, AWS S3 o altro.

Quando si distribuisce software avente un’ampia base di utenti o geograficamente diversificata, è buona pratica copiare il software in più posizioni o repository per ottemperare i requisiti relativi alla scalabilità, disponibilità e alle prestazioni.

A queste copie ci si riferisce spesso come copie mirror. In alcuni casi, in particolare quando si tratta di software utilizzato pubblicamente, i server che ospitano le copie mirror non sono sotto il controllo della software house che ha sviluppato il repository: questo è uno aspetto ovviamente preoccupante sotto il profilo della cyber security, e impone il requisito che un repository software sia autenticato nei confronti dell’autore del software.

Facendo riferimento allo schema di hashing e firma di APT, è possibile osservare che, in effetti, utilizzando la sua firma possiamo autenticare l’autore del file Release: questo significa che per ogni mirror a cui accediamo, possiamo controllare la firma della release per verificare che la copia mirror sia effettivamente una copia esatta (“mirror”, tradotto in specchio) della release originale.

Si potrebbe pensare che firmando il file Release, il software venga distribuito in modo sicuro attraverso mirror non trustati, ma i repository sono spesso ospitati senza TLS, e molti utenti credono che sia sufficiente la firma del rilascio per proteggere la rete di distribuzione: sfortunatamente non è così, e chi pensa questo è vittima di un bias cognitivo (o nella peggiore delle ipotesi sta volutamente ingannando i suoi clienti).

In letteratura sono censiti diversi attacchi informatici che possono potenzialmente verificarsi quando ci si connette a un repository mirror non attendibile, nonostante il fatto che l’artefatto che stiamo scaricando sia firmato.

Ad esempio, è possibile per un attacker forzare il downgrade a una release precedente (firmata), e l’artefatto servito sarà ancora legittimo. Altri vettori di attacco possono includere il targeting del client stesso della gestione dei pacchetti. Nell’interesse della protezione dei tuoi clienti, assicurati sempre che si connettano a un mirror di distribuzione affidabile.

La carenza di repository crittograficamente protetti da TLS presenta potenzialmente un’altra vulnerabilità nella distribuzione del software: gli aggressori che dovessero essere in grado di modificare la risposta HTTP (dunque non protetta) potrebbero eseguire i medesimi attacchi informatici che potrebbe subire un mirror non attendibile.

Pertanto, una soluzione a questo problema è spostare la distribuzione dei pacchetti su meccanismi protetti da TLS: aggiungendo infatti un layer TLS, i client possono verificare (sia da CLI che da GUI) che si stanno effettivamente connettendo a un repository affidabile.

Con una pipeline Secured by Design sarà possibile prendere decisioni ponderate su dove dipendenti e consulenti debbano essere coinvolti in quella pipeline. Limitando il coinvolgimento umano solo ad alcuni punti chiave, la pipeline di rilascio rimarrà sicura garantendo allo stesso tempo che i potenziali aggressori non saranno in grado di sfruttare la manipolazione e l’automazione della pipeline stessa per distribuire software dannoso. La possibilità di inserire o modificare codice nei sistemi di controllo delle versioni (VCS) del software è uno scenario in cui generalmente sono coinvolti esseri umani: a seconda dell’autorevolezza e dell’importanza del progetto, imporre agli sviluppatori di archiviare solo i commit firmati costituisce una best practice che ha l’obiettivo di autorizzare i soli commit autenticati tramite PKI.

Una volta caricati i commit, non sarà necessario che gli sviluppatori siano coinvolti nella realizzazione degli artefatti software. Tali artefatti, infatti, dovrebbero idealmente essere compilati automaticamente in un sistema protetto.

Gli sviluppatori dovrebbero, tuttavia, essere coinvolti nella valutazione di quale release debba o meno essere distribuita.

Questo coinvolgimento può essere implementato utilizzando vari meccanismi: copiando un artefatto dal database di build al database di rilascio, piuttosto che taggando un particolare commit nel controllo del codice sorgente, per esempio.

Esistono vari meccanismi con cui gli sviluppatori possono certificare un file binario prima di un rilascio in produzione, ma indipendentemente dal meccanismo applicato, è doveroso che risulti estremamente protetto, collaudato e crittograficamente non ingannabile.

Quando si ingegnerizzano sistemi sicuri si è tentati di applicare contromisure approfondite per mitigare qualsiasi minaccia informatica immaginabile, ma l’onere imposto agli esseri umani dovrebbe essere bilanciato rispetto al potenziale rischio: nel caso di un software distribuito globalmente, la chiave privata dovrebbe essere custodita con la massima attenzione, poiché nello scenario peggiore, lo sforzo necessario per ruotare una chiave compromessa risulterebbe molto oneroso.

Le organizzazioni che rilasciano software come questi utilizzano comunemente “cerimonie di firma del codice”, in cui la chiave usata per la firma digitale viene archiviata in un Modulo di Sicurezza Hardware (HSM) e sbloccata utilizzando l’autorizzazione a più parti come meccanismo di mitigazione contro l’eventuale furto di questa chiave di massima sicurezza.

Relativamente al software destinato ad uso interno, lo sforzo necessario per ruotare una chiave è computazionalmente inferiore; quindi, è possibile optare per pratiche di sicurezza informatica più permissive, tuttavia, per applicazioni interne particolarmente critiche – ad esempio un sistema che memorizzi i dettagli delle carte di credito – un’organizzazione potrebbe comunque preferire una cerimonia di firma del codice.

Bit9 (oggi Carbon Black, acquistata nel 2019 da VMware) era una società di sicurezza informatica che sviluppava un’applicazione che consentiva l’inserimento delle applicazioni in whitelist. Avevano molti clienti di alto profilo, dalle agenzie governative ad aziende nominate tra le Fortune 100: nel 2013, un attacco informatico condotto contro la loro rete ICT (avviato grazie allo sfruttamento di una vulnerabilità di tipo SQL Injection, come indicato qui) ha consentito agli aggressori di recuperare una delle chiavi private di firma del codice del loro software, che è stata poi utilizzata per firmare e installare malware in una manciata di clienti.

È opinione diffusa che sia stato fatto per aggirare l’hardening fornito dal software stesso di Bit9, e questo episodio dovrebbe rammentarci l’importanza di proteggere le chiavi di firma del codice: se corri un rischio elevato, come lo correva Bit9, potrebbe non essere una cattiva idea quella di impiegare una cerimonia di firma del codice.

Trustare istanze

Quando si progetta una rete Zero Trust, conoscere cos’è in esecuzione nella tua infrastruttura è fondamentale, dopotutto, come puoi sapere cosa aspettarti dalla tua rete se non sai cosa aspettarti dai tuoi host?

Una conoscenza approfondita del software (nonché delle esatte versioni) in esecuzione nel tuo data center contribuisce notevolmente sia al rilevamento delle violazioni che alla mitigazione delle vulnerabilità.

Le versioni del software e delle librerie costituiscono informazioni fondamentali per determinare esattamente quali release dell’applicazione del tuo fornitore hai in esecuzione. Probabilmente, la cosa più importante è che i numeri di versione vengono utilizzati per determinare a quali vulnerabilità può essere esposto un certo server o un certo appliance, data la versione in esecuzione (messaggio per i miei ex allievi di marzo 2024: vi ricordate il laboratorio di penetration testing che abbiamo messo in piedi per sfruttare Log4j? E di come OpenVAS ci avesse effettivamente segnalato la presenza della vulnerabilità in quel portale?).

I bollettini di sicurezza relativi alle vulnerabilità sono in genere associati a un ben preciso numero di versione, e, se il vendor ha patchato la problematica, includono anche la release in cui la vulnerabilità è stata corretta.

Tenendo presente questo scenario, non è escluso ipotizzare che un attacker desideri forzare un downgrade della versione in produzione per sfruttare una vulnerabilità nota: si tratta di un vettore di attacco realistico, poiché generalmente il software che si avvia, nella maggior parte delle organizzazioni spesso è eseguito con privilegi amministrativi, ma anche poiché si tratta di una versione perfettamente valida, sebbene più vecchia e vulnerabile.

Se il software è stato progettato per un uso interno, probabilmente il sistema di distribuzione fornirà solo la versione più recente.

In questo modo si impedisce a un sistema compromesso o configurato in maniera superficiale (“Italian style” dico io, come accade ad esempio in numerose amministrazioni pubbliche) di rimuovere una versione desueta che potrebbe contenere una vulnerabilità popolarmente sfruttata.

È anche possibile applicare questo approccio di roll-forward all’hardware. Apple iOS, ad esempio, utilizza un chip di sicurezza hardware per convalidare gli aggiornamenti software e garantire che possa essere caricato il solo software firmato creato dopo la release attualmente operativa sul dispositivo.

Autorizzazione delle istanze

La priorità di conoscere con esattezza cosa c’è in esecuzione su di una workstation piuttosto che in LAN è decisamente più sfumata rispetto alla semplice comprensione di qual sia l’ultima versione distribuita del software.

Possono verificarsi molti casi limite: ad esempio un host che è uscito dal sistema di distribuzione, piuttosto che un altro che è stato precedentemente autorizzato ma ora è diventato vetusto poiché non riceve più aggiornamenti da mesi.

Per prevenire casi come questi, è fondamentale che le istanze in esecuzione siano autorizzate individualmente.

È possibile utilizzare le tecniche descritte negli articoli precedenti per definire una policy di rete dinamica nel tentativo di autorizzare le istanze dell’applicazione, ma le policy di rete spesso sono orientate all’host/dispositivo piuttosto che alle applicazioni. Invece, nel tentativo di autorizzare un’istanza in esecuzione, è possibile sfruttare qualcosa di molto più mirato all’applicazione: i segreti.

La maggior parte delle applicazioni in esecuzione richiedono una sorta di parola d’ordine o segreto per svolgere il proprio lavoro.

Questa parola d’ordine può palesarsi in modi differenti: un’API key, un certificato X.509 o anche le credenziali di una coda di messaggi. Per poter essere eseguite, le applicazioni devono ottenere i segreti e, soprattutto, il segreto dovrà essere validato.

La validazione di un segreto (per quanto ovvio possa sembrarci) è la chiave di volta per autorizzare un’applicazione in esecuzione, poiché l’avvenuta convalida genera automaticamente l’invalidazione nel caso di un tentato utilizzo successivo.

Creando un nuovo segreto per ogni istanza distribuita e associando una durata al segreto possiamo sapere esattamente cosa c’è in esecuzione, poiché sapremo esattamente quanti segreti abbiamo generato, a chi li abbiamo associati nonché la loro durata.

Applicare la scadenza ai segreti mitiga l’impatto di eventuali istanze canaglia garantendo che non potranno funzionare all’infinito.

Ovviamente, qualcuno dovrà essere responsabile della generazione e della consegna di questi segreti in fase di esecuzione, e questa non è una responsabilità di poco conto. Il sistema che si assume questa responsabilità è in definitiva il sistema che autorizza l‘Esecuzione dell’istanza.

Pertanto, generalmente questa responsabilità ricada nelle mani del sistema di Distribuzione, poiché gestisce già una responsabilità simile.

È facile comprendere la portata di un sistema informatico in grado di creare e recuperare segreti. Ovviamente, da un grande potere deriva una grande responsabilità: se consentire a un sistema autonomo di poter generare e distribuire segreti comporta rischi eccessivi per la tua organizzazione, in questa fase potresti prendere in considerazione l’inclusione di un funzionario o di un analista InfoSec.

Idealmente, questo scenario si manifesta come un’implementazione approvata da un funzionario a cui viene fornito un TOTP o un altro codice di autenticazione.

A sua volta, questo codice verrà utilizzato per autorizzare la creazione e il recupero dei segreti da parte del sistema di distribuzione.

Tuttavia, confidare in un’istanza dell’applicazione che è stata autorizzata costituisce solo metà dell’opera. È anche necessario verificare che possa funzionare in modo sicuro e protetto durante tutto il suo ciclo di vita.

Sappiamo come distribuire un’applicazione in modo sicuro e verificare che la sua distribuzione sia autorizzata, ma siamo certi che rimarrà una distribuzione autorizzata e affidabile anche durante tutta la sua vita informatica? Esistono molti vettori d’attacco che possono compromettere istanze di applicazioni perfettamente autorizzate, e potrebbe sorprenderti apprendere che questi sono i vettori più comunemente utilizzati.

Ad esempio, in genere è più facile corrompere un agente governativo esistente piuttosto che mascherarsi da tale o tentare di diventarlo. Per questo motivo, agli individui con debiti insoluti generalmente viene negato il Nulla Osta Sicurezza(NOS).

Potremmo avere piena fiducia in loro nel momento in cui viene concessa loro l’autorizzazione, ma quanto realmente sono riluttanti alla corruzione se hanno già maturato debiti? In futuro ci si potrà fidare sempre di loro?

Pratiche di secure coding

La maggior parte delle vulnerabilità applicative nascondono spesso bug latenti che un attacker può sfruttare per costringere l’applicazione attendibile ad eseguire azioni indesiderate. Risolvere ogni bug in maniera isolata si traduce spesso in un gioco al massacro, in cui gli sviluppatori correggono un bug che ha un impatto sulla sicurezza informatica solo per generarne altri due con quella mitigazione.

Per ovviare realmente a questa esposizione è necessario un cambiamento radicale di mentalità da parte degli sviluppatori di applicazioni.

Gli attacchi di tipo Code injection, ad esempio, in cui i dati forniti dagli utenti vengono manipolati o direttamente forniti ad arte per sfruttare un punto debole di un’applicazione o di un sistema correlato, si verificano comunemente quando i dati inviati dal client non vengono adeguatamente convalidati prima di essere elaborati lato server.

Questo tipo di attacco viene mitigato introducendo diversi livelli di difesa. Le librerie dell’applicazione dovrebbero gestire con attenzione le API che a loro volta dovrebbero evitare di fidarsi ciecamente dei dati forniti dall’utente.

Le librerie di interrogazione del database, ad esempio, dovrebbero fornire un set di API per consentire al programmatore di separare le query statiche dalle variabili fornite dall’utente: istituendo quindi una chiara separazione tra logica e dati, il rischio di attacchi basati su injection viene notevolmente ridotto.

Disporre di API testate e ampiamente documentate può anche consentire la scansione automatizzata del software applicativo.

Le organizzazioni attente alla sicurezza informatica utilizzano sempre di più strumenti di analisi applicati al proprio codice sorgente per rilevare e avvisare gli sviluppatori di pratiche di codifica deficitàrie dal punto di visto della cyber security.

Questi sistemi per l’analisi statica del codice (SAST) avvisano, ad esempio, anche dell’utilizzo di API non sicure, evidenziando le query del database programmate utilizzando la concatenazione di stringhe invece dell’ipotetica API discussa in precedenza.

Oltre ad avvisi relativi alle API insicure, è possibile tracciare la logica dell’applicazione per identificare i controlli di sicurezza mancanti o carenti. Ad esempio, questi strumenti possono confermare o meno che ogni transazione di sistema includa o meno un controllo di autorizzazione, così da mitigare quelle vulnerabilità che consentono agli aggressori di far riferimento a dati e sistemi a cui normalmente non dovrebbero essere autorizzati ad accedere.

Questi esempi rappresentano solo alcune delle funzionalità possedute dagli strumenti di analisi statica (SAST) e dinamica del codice (DAST), di cui tra l’altro mi occupo anche nei miei corsi di Cybersecurity.

L’identificazione sistematica delle vulnerabilità note è diventato un requisito europeo (vedi la direttiva NIS 2, ad esempio), ed ormai nel 2024 è una pratica industrialmente nota (ma forse non altrettanto sempre applicata in Italia), ma molte altre vulnerabilità sono invece troppo subdole per essere rilevate in modo deterministico.

Di conseguenza, un’altra tecnica di mitigazione applicabile è il fuzzing: con questa tecnica vengono inviati dati casuali alle applicazioni in esecuzione per riscontrare eventuali errori o eventi imprevisti.

Questi errori, quando vengono scoperti, spesso costituiscono una base su di cui gli aggressori lavorano per sviluppare exploit e payload sfruttabili per accedere al sistema abusivamente. Il fuzzing può essere eseguito come parte di una suite di test funzionali nelle prime fasi della pipeline in costruzione, o anche in modo continuativo sull’infrastruttura informatica.

I programmatori dovrebbero familiarizzare con le pratiche di Secure Coding più appropriate per migliorare preventivamente la sicurezza informatica nelle loro applicazioni.

Molte organizzazioni scelgono di affidare a consulenti InfoSec esterni l’ispezione delle proprie applicazioni e la revisione delle pratiche di sviluppo software interne al fine di identificare correttamente i rischi e le criticità non evidenziati tempestivamente dai team interni, e non a caso.

Isolamento

Isolare le applicazioni distribuite limitando l’insieme di risorse a cui possono abitualmente accedere è fondamentale in un’architettura di rete Zero Trust.

Normalmente le applicazioni vengono avviate ed eseguite all’interno di un ambiente condiviso, in cui i programmi di un utente vengono eseguiti in un ambiente esecutivo con pochissimi vincoli su come le applicazioni possono interagire.

Questo ambiente esecutivo condiviso genera una grande quantità di rischi nel caso in cui un’applicazione venga compromessa, e presenta sfide analoghe a quelle del modello perimetrale.

L’isolamento mira a limitare i danni di un’applicazione potenzialmente compromessa definendo anticipatamente le risorse disponibili per quella specifica applicazione.

L’isolamento limita, a fin di bene, le capacità e le risorse fornite dal sistema operativo alle applicazioni, come ad esempio:

1. lo sfruttamento temporale della CPU;
2. gli accessi di memoria;
3. la quantità di traffico di rete;
4. gli accessi al file system;
5. le chiamate alle primitive di sistema.

Configurato a puntino, l’isolamento tecnicamente impone che ad ogni applicazione venga concesso il minimo necessario per completare le proprie attività.

Un attacker che dovesse compromettere un’applicazione vincolata scoprirà a suo spese che non gli sarà possibile effettuare nessuna escalation di privilegi, tantomeno movimenti laterali.

Di conseguenza, isolando opportunamente le applicazioni, il danno potenziale derivante da un’ipotetica applicazione compromessa viene ridotto, per non dire completamente annullato: in un ambiente multiprocesso (ad esempio, un server che esegue diversi servizi) infatti, ulteriori servizi ancora sicuri saranno protetti dai tentativi di spostarsi lateralmente su quel sistema, e potranno sosituire tempestivamente il sistema compromesso.

Nel momento in cui sto scrivendo, l’isolamento può essere realizzato avvalendosi di una o più delle seguenti tecnologie, ampiamente collaudate:

1. SELinux, AppArmor
2. gabbie (jails) BSD
3. Docker
4. Sandbox
5. AppContainer di Microsoft

Ad alto livello, possiamo suddividere l’isolamento in due tipi: virtualizzazione e ambienti kernel condivisi. La virtualizzazione è spesso considerata più sicura, poiché l’applicazione è contenuta all’interno di un ambiente hardware virtuale, servito da un hypervisor esterno all’ambiente di esecuzione della VM.

Avere un confine ben delineato tra l’hypervisor e le macchine virtuali vuol dire definire una superficie di protezione ben precisa tra il sistema Host e le VM guest.

Viceversa, i sistemi che si avvalgono di kernel condivisi, come quelli utilizzati in ambienti containerizzati o con policy applicative, forniscono alcune garanzie di isolamento, ma non nella stessa misura di un sistema completamente virtualizzato.

Un ambiente di esecuzione del kernel condiviso utilizza meno risorse per eseguire lo stesso insieme di applicazioni, e indubbiamente risulta favorito nelle organizzazioni attente ai costi.

Mentre la virtualizzazione cerca di affrontare il problema dell’efficienza delle risorse, fornendo un accesso più diretto all’hardware sottostante, i vantaggi in termini di sicurezza informatica dell’ambiente virtualizzato iniziano a somigliare sempre più agli ambienti a kernel condiviso.

A seconda del modello di minaccia informatica, è possibile optare di non condividere affatto l’hardware.

Monitoraggio attivo

Come per qualsiasi sistema in produzione, un logging meticoloso unito ad un monitoraggio attento e tempestivo costituiscono insieme uno strumento di autodifesa cibernetica formidabile, ergo sono della massima importanza nel contesto della cyber security.

I modelli di sicurezza tradizionali focalizzano la loro attenzione sui vettori di attacco esterni, viceversa, le reti Zero Trust incoraggiano e pretendono lo stesso livello di attenzione anche per le attività interne.

Una prevenzione ingegnerizzata che contempli il rilevamento tempestivo di un attacco informatico può fare la differenza tra la compromissione completa dei sistemi informativi (come accade ancora oggi a molte organizzazioni che non investono o investono male nel settore della cyber security) e l’applicazione tempestiva dei piani di Incident Response testati nel tempo.

Oltre al logging minuzioso (quante sono ancora oggi, in Italia, le organizzazioni sciagurate che non effettuano DATA QUALITY dei LOG?) degli eventi di sicurezza informatica di tutta l’infrastruttura (banalmente come accessi non riusciti e riusciti) che generalmente viene considerato monitoraggio passivo, esiste anche un’intera classe di monitoraggio attivo.

Ad esempio, le scansioni fuzzing a cui ho accennato in precedenza, richiedono tempo per scoprire nuove vulnerabilità, sicuramente molto più tempo di quello che generalmente si è disposti a dedicare all’inizio di una pipeline di rilascio.

Una strategia di monitoraggio attivo prevede che le scansioni vengano eseguite anche sulla produzione, in modo continuativo.

Ovviamente, il fuzzing è solo un esempio. Le scansioni automatizzate sono uno strumento utile per garantire un comportamento coerente dei sistemi.

Ad esempio, un database dei soli daemon autorizzati nello stato listening potrebbe essere confrontato con una scansione automatizzata dei servizi effettivamente in ascolto sul device in quel momento in modo da poter evidenziare e gestire i delta (perché il tal o tal altro servizio è inaspettatamente in listening se non è previsto dalla direttiva?).

Tuttavia, non tutte le scansioni danno luogo a un’evidenza così cristallina: le scansioni del software installato, ad esempio, vengono generalmente utilizzate per stabilire la priorità degli aggiornamenti in base alle minacce informatiche a cui una rete è esposta o potenzialmente esposta in futuro.

Una scansione efficace del sistema richiede più scanner, ognuno dei quali ispeziona il sistema in modo leggermente diverso. Ecco alcuni esempi di tipi differenti di scanner:

1. fuzzing (AFL-fuzz, wfuzz ecc.);
2. injection scanner (Sqlmap ecc.);
3. scanner di porte/servizi (Nmap ecc.);
4. scanner di vulnerabilità conosciute (Nikto, Nessus, Metasploit ecc.);
5. scanner di password (hydra, patator, wfuzz ecc.) e risorse.

Quindi, cosa fare quando i penetration tester scoprono effettivamente qualcosa? La risposta in genere dipende dalla portata della scoperta, dalla gravità della vulnerabilità e dall’importanza critica dell’asset.

Tradizionalmente, gli eventi sospetti (ma non critici) vengono inseriti nei report ed esaminati periodicamente.

Questo approccio è di gran lunga il meno efficace, poiché può portare ad un pericoloso sovraccarico delle segnalazioni, che dalla mia esperienza passano inosservate nelle settimane o addirittura nei mesi seguenti la prima segnalazione.

In alternativa, gli eventi effettivamente critici sollecitano diverse riunioni per un’indagine attiva e operativa, ergo, questi eventi dovrebbero generare un poderoso segnale acustico da provocare il risveglio tempestivo di qualche dirigente che abbia accesso alle leve decisionali e strutturali del sistema informatico: nella maggior parte dei casi, questa è la linea di difesa più efficace.

Nelle organizzazioni altamente automatizzate, tuttavia, esiste una terza opzione: la risposta proattiva. Le segnalazioni di massima priorità che “qualcosa non va” possono innescare azioni automatizzate nell’infrastruttura.

Questo, ad esempio, può significare dover revocare le chiavi assegnate ad un’istanza sospetta, escluderla dall’appartenenza al cluster o persino segnalare al software di gestione del data center che l’istanza deve essere messa offline o isolata per scopi di digital forensics.

Naturalmente, come con qualsiasi automazione ad alto livello, si possono causare molti danni e molto rapidamente quando si utilizzano risposte attive senza le dovute verifiche e precauzioni.

Con tali meccanismi è possibile favorire attacchi di negazione del servizio (DoS), o magari provocare involontariamente l’interruzione di un servizio a causa di negligenze da parte di qualche operatore.

Quando si progettano sistemi a risposta proattiva, è fondamentale mettere in atto una serie di misure cautelative.

Ad esempio, una risposta proattiva che espelli un host da un cluster non dovrebbe attivarsi se la dimensione del cluster è pericolosamente bassa: essere lungimiranti nel definire i limiti delle reazioni attive, come in questo esempio, garantisce la sicurezza e l’efficacia del processo stesso di Incident Remediation.

Conclusioni

In questa puntata ho cercato di illustrare, a grandi linee, come debbano essere protette le applicazioni in una rete Zero Trust. Potrebbe sembrare poco sensato che una rete Zero Trust debba preoccuparsi della sicurezza delle applicazioni (dopotutto per definizione parte dall’assunto che la rete non è affidabile) quindi che sulla rete siano presenti applicazioni non sicure, dovrebbe essere uno scenario scontato.

Tuttavia, mentre una rete ZTS opera rilevando e identificando le attività delle applicazioni dannose, tale obiettivo diventa una chimera se le applicazioni distribuite non vengono adeguatamente controllate prima di essere autorizzate all’esecuzione.

Di conseguenza, è prioritario focalizzarsi su come sviluppare, creare e distribuire applicazioni in maniera sicura, successivamente provvedere al monitoraggio continuo delle istanze in esecuzione affinché rimangano affidabili.

Ho altresì introdotto il concetto di pipeline di applicazioni fidate, ovvero il meccanismo mediante il quale il software realizzato da programmatori fidati viene trasformato in un’applicazione affidabile e fidata che verrà distribuita nell’infrastruttura.

Questa pipeline costituisce un obiettivo di hacking pregiato per gli attacker, quindi merita un’attenzione speciale.

In seguito, ho trattato delle pratiche di hosting sicuro del codice sorgente, le best practice per compilare il codice sorgente in artefatti affidabili, nonché la selezione e distribuzione sicura di tali artefatti ai consumatori/utenti a valle.

La pipeline dell’applicazione applica una serie di trasformazioni immutabili sull’input ricevuto in precedenza, quindi ho accennato a come raggiungere gli obiettivi di tale pipeline senza introdurre troppi attriti nel processo.

L’attenzione di un sistemista o di un tecnico sono sempre risorse scarse ma imprescindibili in un sistema sicuro, e con le frequenze di rilascio software in costante aumento, è opportuno considerare attentamente quanti (e quali) essere umani coinvolgere nel processo di CI/CD.

Una volta create le applicazioni, occorre ragionare sul processo garante della loro esecuzione continuativa in un ambiente di produzione.

Le attuali applicazioni attendibili, in futuro potrebbero non esserlo più man mano che vengono scoperte vulnerabilità, quindi ho discusso dell’importanza di una policy di aggiornamento durante l’esecuzione delle applicazioni. La gestione dei segreti (API key e affini) risulta spesso un compito arduo per i CISO e per gli analisti InfoSec, poiché la modifica delle credenziali si rivela spesso insidiosa in termini di gestione. Con un processo di provisioning dinamico delle credenziali emerge una nuova opportunità per le applicazioni fidate nel tempo: utilizzando infatti il processo stesso di cambio delle credenziali, è possibile mettere in piedi un meccanismo per garantire che in produzione continueranno ad essere operative le sole applicazioni autorizzate. Infine, apprendere (e far doverosamente applicare) rigorose pratiche di Secure Coding, distribuire applicazioni (quanto più possibile) in ambienti isolati e/o segmentati, e quindi monitorare le applicazioni e gli eventi generati da esse stesse e dagli utenti in modo sistematico, tempestivo e strutturato è l’ennesimo passo da attuare per poter gestire in sicurezza un ambiente di produzione che possa realmente definirsi parte di un’autentica rete Zero Trust.