In accordo con uno studio condotto da Synopsys, la diffusione del software open source nel 2021 è cresciuta ulteriormente ed è così prevalente che i proprietari delle app che lo utilizzano non sono molto spesso nemmeno a conoscenza di quanti e quali siano i componenti open source del proprio software.
Nel 2016 la media di componenti open source era di 84 per app, mentre nel 2020 si è raggiunto il numero medio di 528.
Chiara conseguenza è che i software sviluppati con tali componenti abbiano al proprio interno anche le vulnerabilità che li affliggono. Secondo Synopsys l’incremento del numero di vulnerabilità tra il 2019 ed il 2020 è stato del 9%, il secondo più alto anno su anno da quando lo studio è stato avviato.
Parallelamente si è assistito anche all’aumento delle vulnerabilità critiche: +11% rispetto all’anno precedente. La maggior parte di esse sono presenti nel codice da più di due anni e hanno soluzioni documentate.
La vulnerabilità emersa recentemente all’interno di Log4j (CVE-2021-44228) ha messo in mostra, secondo molti, le criticità dell’utilizzo di software open source, con numerose testate che hanno cavalcato l’onda del panico: tra queste, il Financial Times che ha titolato “Open source can be open door for hackers“.
Queste preoccupazioni derivanti dall’utilizzo del software open source sono giustificate?
Log4Shell: ecco come funziona l’exploit della vulnerabilità di Log4j
Indice degli argomenti
I principali incidenti di sicurezza del 2021
Proviamo a tornare con la mente ad alcuni dei principali incidenti di sicurezza del 2021:
- Florida Water Utility: un attaccante riesce ad avere accesso ad un sistema di un operatore sfruttando credenziali di Teamviewer compromesse. In seguito all’incidente viene reso noto che le credenziali erano presenti in un Google Document pubblicamente disponibile e che la compagnia utilizzava numerosi software obsoleti o in EoL;
- varie organizzazioni vengono compromesse a causa di un servizio di trasferimento file fornito da Accellion. Sono esposti i dati di dipendenti e milioni di clienti;
- PrintNightmare (CVE-2021-34527). Problematica dovuta alla tecnologia Print Spooler di Microsoft Windows. Un attaccante non autenticato aveva la possibilità di eseguire codice malevolo da remoto;
- Exchange Server – ProxyLogon. Vulnerabilità resa nota in Marzo ed in grado di scatenare il panico, soprattutto per la disclosure effettuata da Microsoft che diceva che tale criticità era già ampiamente sfruttata da settimane dal gruppo ATP Hafnium;
- Kaseya VSA: un affiliato al gruppo REvil/Sodinokibi, sfruttando tre vulnerabilità presenti nel software VSA, riesce a distribuire ransomware su migliaia di sistemi appartenenti ai clienti degli MSP che utilizzavano la soluzione Kaseya;
- Log4j: una vulnerabilità critica del logging framework permette agli attaccanti di eseguire codice da remoto.
Tutti questi eventi dimostrano chiaramente come il software open source non sia un problema di sicurezza più di quanto lo sia il software closed source o quanto lo sia la scarsa formazione in ambito cyber security che viene fornita al personale.
Anzi, se volessimo rivalutare con attenzione, probabilmente il software open source è persino meno problematico, per le caratteristiche intrinseche del processo di sviluppo e la disponibilità pubblica del codice che può quindi essere validato e valutato da diverse entità e non da una singola compagnia.
Log4j e sostenibilità del software open source
Quanto accaduto con Log4j non deve e non può diventare la ragione per cui non si debba utilizzare software open source. Deve invece essere un punto di partenza per approfondire e comprendere il complicato tema della sostenibilità del software open source.
I bug sono e saranno sempre presenti, si verificano per una serie di cause molto complesse e non c’è nulla che si possa fare per evitarlo. L’unica via percorribile è quella di capire come mitigare le conseguenze e prepararsi alla prossima criticità.
Finanziare i progetti open source potrebbe avere un impatto significativo sulla prevenzione dei problemi di sicurezza? Probabilmente no e principalmente per due motivi.
Da un lato i responsabili dei progetti open source generalmente sviluppano il software non per mire economiche ma semplicemente per passione e non vogliono alcun tipo di ingerenze da parte di aziende. Parimenti è innegabile, come si evince dai più gravi incidenti occorsi quest’anno, che anche il software sviluppato in ambito Enterprise, con fondi ingenti, sia soggetto alle medesime criticità.
Il fondatore di Ruby on Rails, David Heinemeier Hansson, ha ad esempio dichiarato che non permetterà a nessuno di pagare per il proprio software open source, perché “Open source, as seen through the altruistic lens of the MIT gift license, has the power to break us free from this overly rational cost-benefit analysis bulls— that’s impoverishing our lives in so many other ways.”, confermando ancora una volta che chi contribuisce a questi tipi di progetti non voglia sentirsi obbligato a fare qualcosa che non porti gioia e soddisfazione.
Uso più responsabile dell’open source in ambito commerciale
Oggi il panico viene scatenato da Log4j, ma quanti exploit non ancora scoperti sono già presenti nei software che utilizziamo? Quanti investimenti in sicurezza sono stati effettuati? Ci stiamo muovendo in maniera proattiva o siamo semplicemente in attesa di essere le prossime vittime?
È innegabile che gran parte di Internet sia dipendente da software sviluppato e mantenuto da persone nel proprio tempo libero e che con ciò sorgono numerose criticità.
Non è corretto tuttavia colpevolizzare questi sviluppatori per il fatto che aziende di varie dimensioni traggano vantaggio, generalmente in maniera gratuita, da software sviluppato per progetti senza un chiaro scopo commerciale. Molto spesso il software open source viene fornito, correttamente, as it is e gli utilizzatori dovrebbero rendersi conto che avere aspettative di qualsiasi tipo sia completamente errato.
L’assunto a cui generalmente si assiste, cioè che il software sia sicuro di per sé e che lo sviluppatore si impegni a mantenere un alto livello di sicurezza è errato. Gli sviluppatori di Log4j ad esempio non hanno alcun tipo di obbligazione rispetto al mantenimento e allo sviluppo di patching.
Probabilmente sarebbe più responsabile, per chi utilizza software open source in ambito commerciale e per operazioni critiche, ma anche per chi usa software closed source, che abbiamo visto essere tutto fuorché intrinsecamente sicuro, dotarsi di competenze per lo studio e la validazione del codice utilizzato, in modo da comprenderne le criticità e mettere in campo le adeguate azioni per limitare l’impatto di bug e vulnerabilità.
Open source o closed source: rischi identici
La vera questione che emerge di fronte agli eventi delle scorse settimane non è quindi come risolvere i rischi legati al software open source o closed source, ma al software in generale.
Synopsys viene ancora in nostro aiuto con una top 10 delle best practice da mettere in campo:
- applicare patch a software e sistemi operativi. Non è chiaramente possibile mantenere il software aggiornato se non sappiamo che software utilizziamo. È quindi necessario mantenere un inventario di tutti i componenti, tramite ad esempio SCA tools;
- formare ed educare gli utenti, tramite corsi di awareness e di secure coding, regolarmente e non solamente una volta all’anno;
- automatizzare i task di routine, come ad esempio l’analisi delle modifiche ai servizi esposti;
- least privilege: assicurarsi che gli utenti abbiano sempre i minimi privilegi per eseguire i propri task;
- creare un robusto piano di incident response: è possibile essere vittime di un attacco, fondamentale è come si è pronti a rispondere;
- documentare le policy di sicurezza;
- segmentare la rete seguendo il principio di least privilege;
- integrare le attività di software security nel ciclo di vita dello sviluppo del software, come ad esempio code review, analisi statica e dinamica e penetration testing;
- monitorare l’attività degli utenti per verificare che stiano effettivamente seguendo le best practice indicate;
- definire delle metriche chiave che possano fornire una valutazione della postura di sicurezza.
Da sottolineare come una buona parte delle azioni di analisi della sicurezza del software possano essere automatizzate, con i corretti tool, per fornire una visione quotidiana dello stato della sicurezza di ciò che di fatto è il core della maggior parte delle aziende.
