Prima lezione: anche se non ci piace ricordarlo, nessun software potrà mai essere esente da bug dei tipi più vari e quanto successo con le vulnerabilità scoperte nella libreria Log4j ci ricorda l’importanza di realizzare un efficiente piano di vulnerability management.
I processi che abbiamo oggi sono in massima parte volti ad assicurarci che l’impatto sia trascurabile per quanto riguarda le funzionalità. Molto più raramente ci sono dei processi per minimizzare l’impatto di questi bug sulla sicurezza, nonostante le molteplici chiamate alle armi e le grandi promesse che si sono susseguite negli anni.
Quando questo succede, tutti sono molto contenti perché possono dire di avere implementato il celeberrimo “security by design”. Tuttavia, nella pratica, a parte alcuni (abbastanza sporadici, in verità) programmi di bug bounty, non sembra diffusa la tecnica dell’adversarial testing, con il risultato che questo tipo di test viene fatto dai criminali.
Indice degli argomenti
Il software continua a essere pieno di buchi
Ci focalizziamo soltanto sui bug di sicurezza (che chiamiamo vulnerabilità): il tema è largamente noto e, in teoria di facile soluzione: basta installare una versione aggiornata del software in questione (che chiamiamo spesso patch). Tutti i vendor di software rilasciano patch di sicurezza (non era così qualche anno fa, ma ormai la prassi si è consolidata), che si possono scaricare gratuitamente.
In pratica, come dimostrato dai recenti avvenimenti, il problema rimane aperto.
Un dato largamente accettato nell’industria dice che ci sono sono in media tra 10 e 20 vulnerabilità per macchina, indipendentemente dall’istante di misurazione. Questo significa che il problema è gigantesco, e non fa che crescere, grazie anche al moltiplicarsi delle macchine virtuali. In quest’ultimo caso, il loro “tempo di vita”, spesso molto breve, non fa che complicare ulteriormente il problema.
Credo sia evidente che il fattore di scala sia un primo grave ostacolo.
Le vulnerabilità rimangono un problema
Seconda lezione: le vulnerabilità software, a prescindere da quello che ne possiamo pensare, rimangono un problema grave. Il rapporto Clusit lo dimostra chiaramente:
Dal grafico vediamo che solo 13% degli attacchi di cui è nota la tecnica sono eseguiti direttamente tramite vulnerabilità. Tuttavia, è noto che il malware, benché oggi sia diffuso prevalentemente tramite phishing, usa comunque una o più vulnerabilità come secondo passo per fare privilege escalation o lateral movement.
Poiché, inoltre, negli attacchi con tecnica mista possiamo dare per scontato che almeno una certa percentuale usi anche vulnerabilità, possiamo valutare che le vulnerabilità siano coinvolte, direttamente o indirettamente, in almeno due terzi degli attacchi di cui è nota la tecnica.
Questo ci porta a concludere che la gestione delle vulnerabilità rimane un tema di prioritaria importanza, nonostante sia stato da tempo derubricato ad un impegno soprattutto di IT operations che non desta alcuna emozione in chi si occupa di cybersecurity.
Peraltro, su queste stesse pagine si scriveva di vulnerabilità e gestione delle stesse già nel 2018.
Il vulnerability management non è di moda
Terza lezione: la gestione delle vulnerabilità sicuramente non è di moda, e non è probabile che lo diventi. Non si è mai sentito che un CISO sia diventato famoso grazie al suo piano di vulnerability management, e non credo che mai lo sentiremo.
Sappiamo poi che il VM è una fatica di Sisifo: appena hai finito di installare le patch, devi ricominciare a cercare, appaiono nuove vulnerabilità, ed il percorso inizia daccapo.
In realtà, anche solo l’esistenza di un programma regolare e controllato di scansione delle vulnerabilità esistenti è ancora l’eccezione, piuttosto che la regola.
Spesso ci sono notevoli ostacoli per realizzare un programma di questo tipo, e sono a volte più organizzativi che economici o tecnologici; ad esempio, coordinare i vari reparti aziendali, in modo che eventuali malfunzionamenti causati dalla scansione stessa – per quanto rari – possano essere tamponati rapidamente.
A volte, invece, non è possibile utilizzare scansioni attive per la presenza di dispositivi critici che, se andassero in errore a causa di una scansione, causerebbero problemi rilevanti all’azienda (pensiamo al caso di dispositivi di controllo industriale). Esistono, naturalmente, soluzioni tecnologiche ed organizzative che consentono di superare questi impasse; laddove non è possibile una scansione attiva, potrebbe essere possibile, ad esempio, analizzare il traffico di rete in modo passivo, oppure riutilizzare dati raccolti in precedenza calcolando un delta in base a segnalazioni indirette. Si tratta comunque di impegnare una discreta quantità di risorse, e non tutte le organizzazioni hanno la scala per potersele permettere.
Per questi e per altri motivi, dunque, il rilevamento e la mitigazione delle vulnerabilità software non sono argomenti che fanno particolarmente emozionare chi lavora nella cybersecurity. Questo è un dato di fatto, ma la conseguenza è che troppe organizzazioni lo vivono come una seccatura della quale occuparsi il minimo indispensabile, e da delegare non appena possibile a chi si occupa di gestione dei sistemi, ovvero alle IT Operations.
Le soluzioni di gestione
Quarta lezione: l’installazione delle patch è ancora percepita come un processo pesantissimo.
Chi fa IT Operations, dal canto suo, cerca di dotarsi (in genere) di soluzioni il più possibile automatiche per gestire un parco macchine in continua crescita. Tra queste soluzioni ci sono anche quelle che servono per gestire le patch; ed esistono sia per ambienti Microsoft, sia per ambienti Linux, sia per i dispositivi mobili, ecc. Di solito si tratta di console di gestione IT, che, tra le altre cose, consentono di tenere sotto controllo le patch disponibili ed applicabili per ogni computer ed ogni telefonino della rete. Quando ben usate, consentono un ottimo risultato, e anche i costi non sono insormontabili.
Visto che le soluzioni di gestione esistono, non sono particolarmente costose, e sono anche abbastanza efficaci, perché siamo ancora messi così male? Forse nessuno le usa?
Questa deduzione sembra ragionevole. In effetti su Linux (dove c’è il 90% di Log4J) non ci sono soluzioni di larga adozione: alzi la mano chi ha mai sentito parlare di RedHat Satellite. Visti però i diversi meccanismi in essere, nelle varie distribuzioni di Linux per l’installazione dei pacchetti software e dei loro aggiornamenti, è complesso costruire soluzioni cross-platform, ed il mercato comunque non sembra particolarmente ricettivo.
Nel campo Microsoft, a livello aziendale, le soluzioni sono ben note e largamente adottate. Gli strumenti nativi della piattaforma software consentono di gestire la scelta, il download e l’installazione di tutte le patch rilevanti per tutti i sistemi Microsoft gestiti dalla piattaforma stessa. Tali operazioni sono anche largamente automatizzabili. Purtroppo è anche vero che i sistemi Windows sono anche, in larga misura, sistemi client, e pertanto sono particolarmente bersagliati dagli attacchi, che si estendono ai server della stessa famiglia. Come risultato, il livello di aggiornamento complessivo non sembra essere particolarmente diverso da quello dei sistemi Linux e similari.
Tuttavia c’è anche un secondo, e forse più pesante, motivo di ritardo nell’installazione delle patch. Questo è il lock-in causato dall’esistenza in produzione di applicazioni basate sull’una o sull’altra delle varie componenti software vulnerabili. Naturalmente questo implica che l’installazione di una patch, quando non sia totalmente impossibile a meno di “rompere” il sistema in produzione, deve procedere con particolare cautela.
Questo fatto è largamente accettato e noto anche ai grandi vendor di software; per quanto essi ne abbiano beneficiato economicamente in passato (e probabilmente continueranno a beneficiarne in futuro), non sembra di vedere nel mercato segnali d’interesse a mitigare questo problema.
Una vignetta per capire
Quinta lezione: la dipendenza dell’infrastruttura dai suoi componenti è, in larga parte, sconosciuta.
Appare evidente che spesso sia stato sottovalutato, se non interamente ignorato, il rischio portato dai componenti software che provengono da terze parti; componenti che spesso sono frutto degli sforzi di un gruppo molto ristretto di appassionati, che vi si dedicano per passione nel loro tempo libero.
“… and then there’s this fundamental library here, that is maintained by Joe from the local garage in his spare time”
Questo punto è riassunto in modo quasi profetico da una vignetta di XKCD di vari anni fa.
Credo che non serva dire altro.
