Con così tanti team di sicurezza e sviluppatori che eseguono post mortem sul fiasco della vulnerabilità della sicurezza di Log4j che si è verificato alla fine del 2021, appena 10 giorni prima di Natale, la domanda principale è:come possiamo evitare questo tipo di dolore in futuro? La risposta, sfortunatamente, è... è complicato.
Copertura di sicurezza da leggere
Secondo i nuovi dati di (ISC)2, la più grande associazione senza scopo di lucro del mondo di professionisti certificati della sicurezza informatica, quasi la metà (48%) dei team di sicurezza informatica ha rinunciato alle ferie e ai fine settimana per assistere con la riparazione e il 52% dei team ha trascorso "settimane o più ” rimediando Log4j. Non esattamente come gli sviluppatori già stanchi volessero trascorrere le vacanze.
Al rialzo, tuttavia, il dolore di quell'esperienza ha innescato un importante ripensamento della sicurezza della catena di fornitura del software da parte di sviluppatori e team di sicurezza.
Risolvere le vulnerabilità senza violare il codice legacy
Uno degli aspetti più problematici di Log4j non era la vulnerabilità in sé, ma quanto fosse profondamente radicata la tecnologia nel codice legacy. Dopotutto, Java è una delle piattaforme più popolari al mondo e Log4j è un sistema di registrazione Java incredibilmente popolare la cui versione iniziale risale al 2001. Quindi Log4J tocca non solo un sacco di sistemi di produzione, ma anche molti legacy codice.
"Nessuno vuole toccare il codice legacy", ha affermato Sergei Egorov, CEO di AtomicJar, la nuova startup dietro il framework di test di integrazione open source, Testcontainers. “Non devi solo correggere una vulnerabilità di sicurezza, devi sapere che hai risolto la vulnerabilità senza rompere il tuo sistema. Quando hai una vulnerabilità con una libreria di registrazione super popolare come Log4j, stai parlando di dipendenze dal codice legacy che in genere non ha alcun test e dove a volte gli sviluppatori che hanno scritto il codice e capiscono come funziona non lavorano nemmeno in azienda più.”
Secondo Egorov, Log4j è spesso una dipendenza transitiva di altre librerie che devono essere aggiornate. A differenza delle piattaforme che forniscono binari statici, con i sistemi Java il collegamento del codice avviene in fase di esecuzione, quindi non c'è modo di avere la certezza al 100% che l'applicazione si comporterà correttamente fino a quando non la eseguirai e testerai il collegamento in tempo reale tra dipendenze e compilation.
Egorov ha affermato che Log4j ha accelerato l'interesse per la già popolare piattaforma Testcontainers, come un modo per testare queste interazioni prima dell'implementazione della produzione. Vede che gli sviluppatori che sono stati colpiti da Log4j ora creano test di integrazione tra i sistemi e le dipendenze esterne, in modo che la prossima volta che arriva una vulnerabilità di sicurezza, gli sviluppatori possono verificare che le loro correzioni non riducano i sistemi di produzione quando vengono implementati. Testcontainers sta diventando un abbinamento popolare con Snyk, perché gli sviluppatori possono ricevere richieste pull per richieste di sicurezza automatizzate e i test di integrazione danno loro la sicurezza di poterli unire senza interrompere nulla.
Qual è il peggio... la vulnerabilità o l'interruzione degli utenti?
L'arrivo della vulnerabilità di sicurezza di Log4j e il suo terribile tempismo durante l'alta stagione delle vacanze ha creato una scelta perversa per i team di sviluppatori:implementare le correzioni ora e rischiare di disattivare i sistemi durante i cicli di e-commerce durante le festività natalizie, oppure spostare l'implementazione delle correzioni a intervalli meno rischiosi dal punto di vista commerciale ?
È una decisione impossibile da prendere se non si dispone del contesto giusto.
"Log4j ha causato il panico in molti team di ingegneri perché non avevano modo di prevedere in che modo la correzione avrebbe influenzato i loro utenti", ha affermato Marcin Kurc, CEO della startup per l'affidabilità del software Nobl9, i cui clienti includono grandi rivenditori online. "Esiste un'analisi costi-benefici che deve essere eseguita su qualsiasi riparazione della sicurezza. Devi determinare l'intervallo giusto per implementare la correzione, il che richiede una comprensione completa del rischio in termini di numero di utenti che potrebbe interessare e il livello accettabile di inaffidabilità che puoi accettare".
L'azienda di Kurc sta sostenendo un movimento chiamato obiettivi del livello di servizio (SLO) che è nato nelle pratiche di ingegneria dell'affidabilità del sito di Google e che Nobl9 ha commercializzato in una piattaforma.
Gli SLO consentono agli sviluppatori di modellare i tempi di attività e le percentuali di successo nelle interazioni software e di definire soglie per i risultati degli utenti, ad esempio la percentuale di checkout del carrello eseguita correttamente. Le aziende che stanno modellando gli SLO, afferma Kurc, possono avere una vera conversazione sul rischio di applicare le patch rispetto a non applicare le patch.
Tali soluzioni, tuttavia, vengono dopo il fatto o, meglio, dopo che il software open source è stato scritto. Ma cosa facciamo per renderlo intrinsecamente più sicuro?
Un problema più ampio:chi possiede la sicurezza per l'open source?
Nessuno smetterà di usare l'open source. Sarebbe assurdo costruire una soluzione di registrazione da zero, piuttosto che ricorrere a strumenti come Log4j. Al giorno d'oggi gli sviluppatori scrivono meno logica e integrano più framework, librerie e API, e questo non cambierà.
Come ha scritto Filippo Valsorda di Google in un post virale, molti di questi manutentori open source “ricadono in una di due categorie:volontari o dipendenti di grandi aziende. A volte entrambi. Nessuno dei due modelli è sano."
Log4j ha evidenziato il fatto che gran parte della moderna catena di fornitura del software è sostenuta da progetti open source con una manciata di manutentori, o anche un solo manutentore, che spesso ha creato la tecnologia come progetto collaterale. (E siamo chiari:dati recenti suggeriscono che la stragrande maggioranza di tutto il software open source è scritto da meno di 10 persone.)
"Le applicazioni moderne sono costruite da molti componenti, molti dei quali non sono sviluppati internamente ma sono piuttosto assemblati utilizzando soluzioni "pronte all'uso", secondo John France, CISO presso (ISC)2. "Gran parte della qualificazione e dell'identificazione dei problemi consiste nel sapere quali componenti e librerie vengono utilizzati dal software e tenere una distinta base del software (SBOM)."
Ma secondo un professionista della sicurezza anonimo nel sondaggio di riparazione Log4 di (ISC)2, "Gli sviluppatori in generale sono stati molto permissivi nel tracciare ciò che usano nel loro software. Quando un evento come questo ci richiede di identificare se una libreria o un componente viene utilizzato dal nostro codice, quella mancanza di tracciabilità diventa un grave punto dolente. Trasforma un semplice esercizio di controllo delle scorte e delle SBOM in un complesso processo di scansione, con molte opportunità di falsi positivi e falsi negativi. Se mai avessimo bisogno di una sveglia, ne abbiamo una grossa con Log4j."
Google e altri pesi massimi stanno mettendo i muscoli in questa sfida di vulnerabilità della sicurezza open source e il tempo dirà se investimenti più approfonditi e collaborazione con i fornitori possono aiutare a ridurre la frequenza e il dolore di incidenti come Log4j. Ma nel frattempo, gli sviluppatori stanno escogitando strategie per evitare terribili sorprese sulla sicurezza nelle prossime festività natalizie.
Disclosure:lavoro per MongoDB ma queste opinioni sono solo mie.
Link alla fonte