Esiste un prodotto nato dalla mente due esperti di cybersecurity che merita un’attenzione per l’impatto che potrebbe avere sull’utilizzo e l’integrazione del codice di programmazione ed è un’idea innovativa e molto promettente.
Il progetto
Si tratta di VulNow, sviluppato dalla collaborazione tra Cassie Crossley e Valerio Mulas e si tratta di un servizio in grado di individuare vulnerabilità presenti nel codice in produzione dopo che un manutentore ha rilasciato una patch, ma prima che venga registrata una CVE o un’informativa ufficiale. Il servizio si colloca esattamente in questo intervallo di tempo facendo guadagnare tempo prezioso per porre rimedio. Generalmente le pubblicazioni di una CVE, infatti, possono tardare anche di settimane o mesi.
Poiché la falla non è stata ancora codificata e ufficializzata all’interno di una CVE, essa risulterà invisibile ai classici scanner di vulnerabilità ma ampiamente sfruttabile dai malintenzionati tramite il reverse-engineering della patch. Ne consegue che VulNow si posiziona in una “zona franca” altamente pericolosa, andando a garantire una risposta concreta in termini di cybersecurity. Il sistema, quindi, identifica la presenza di una vulnerabilità presente nel codice in modo proattivo e permette di approntare le misure di sicurezza necessarie prima ancora degli strumenti ufficiali.
Interazioni con il quadro normativo
Questa soluzione si presenta come una risposta concreta alla conformità normativa richiesta dal CRA (Cyber Resilience Act) ma anche dalla NIS2.
Cyber Resilience Act
VulNow viene correttamente inserito all’interno del CRA (Cyber Resilience Act) poiché è previsto dalla normativa che i prodotti, prima di essere essere immessi sul mercato, devono essere privi di vulnerabilità sfruttabili note ma non solo; una volta immessi è necessario garantire che le vulnerabilità possano essere risolte tramite aggiornamenti di sicurezza. Se questo non dovesse bastare, il CRA impone ai produttore di identificare e documentare tutti i componenti e le dipendenze del software (almeno di primo livello) in un formato strutturato e leggibile automaticamente, per consentire di risolvere tempestivamente le vulnerabilità tramite aggiornamenti di sicurezza gratuiti, forniti separatamente dagli aggiornamenti di funzionalità (laddove tecnicamente fattibile).
NIS2
Anche in termini di compliance alla NIS2, VulNow risponde molto bene a quanto stabilito dall’art. 25, comma 4, punti a) e b) della normativa. Lo strumento, infatti, si basa sulla capacità di individuazione proattiva che è esattamente quanto richiesto dalla normativa quando si parla d’incidenti significativi:
Un incidente è considerato significativo se:
a) ha causato o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato;
b) ha avuto ripercussioni o è idoneo a provocare ripercussioni su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli.
Come è possibile notare la normativa non colloca gli eventi pericolosi nel passato ma li rende plausibili e impone un’azione proattiva onde evitare perturbazione dei servizi e/o perdite finanziarie. È bene ricordare, in particolare, che la misura PR.PS-06 afferente alle “pratiche di sviluppo sicuro del software sono integrate e le loro prestazioni sono monitorate durante l’intero ciclo di vita del software” impone che i soggetti NIS si adoperino per adottare documentare “pratiche di sviluppo sicuro del codice nello sviluppo del software“. Inoltre la regola ID.RA-08 impone che le vulnerabilità “prontamente risolte attraverso aggiornamenti di sicurezza o misure di mitigazione, ove disponibili, ovvero accettando e documentando il rischio in accordo al piano di trattamento dei rischi“. Ecco quindi che i soggetti NIS2 potrebbero trovare in VulNow una valida soluzione alla risoluzione di vulnerabilità senza dover attendere la pubblicazione ufficiale delle CVE.
Risultati e prestazioni
I risultati ottenuti da VulNow sono stati confrontati con quanto pubblicato nella lista ufficiale dei CVE (proveniente da GitHub, NVD e dal record CVE) su 70 rilevazioni riprodotte a cui è stato successivamente assegnato un CVE pubblicato. Sono state valutate due tipi di corrispondenze:
- una corrispondenza esatta (stessa gravità).
- una corrispondenza di gruppo (gravità identica o adiacente, ad esempio High dove il CVE indica Critical).
Al momento della rilevazione: la gravità di VulNow ha:
- Una corrispondenza esatta nel 43% dei casi.
- Una corrispondenza di gruppo nell’87% dei casi.
- Solo il 13% presenta uno scarto maggiore.
Dopo la riproduzione
Una volta riprodotta una rilevazione e ricalcolato il punteggio in base alle prove raccolte, i risultati sono i seguenti:
- la corrispondenza esatta sale al 56%.
- La corrispondenza di gruppo al 94%.
- Solo il 6% presenta uno scarto maggiore, mentre le restanti differenze sono equamente divise tra valutazioni superiori e inferiori.
Esaminando 67 vulnerabilità che utilizzano lo standard di valutazione CVSS versione 3.1 il punteggio riprodotto fornisce la stessa gravità del punteggio ufficiale: 3.1 nel 57% dei casi. Inoltre fornisce la stessa gravità o una adiacente nel 97% dei casi: 8 su 8 Critical, 32 su 33 High e 25 su 26 Medium.
Per le vulnerabilità riprodotte che rientrano nella Top 25 delle debolezze software più pericolose del MITRE (CWE Top 25), la gravità stimata da VulNow corrisponde a quella ufficiale del CVE nel 50% dei casi, e coincide o è adiacente nel 95% dei casi. Inoltre, la classificazione del tipo di debolezza (CWE) effettuata da VulNow corrisponde a quella ufficiale nel 79% dei casi al momento della prima rilevazione e nell’84% dopo la fase di riproduzione.
Falsi positivi
Su 54.831 rilevazioni effettuate ad oggi, 5.409 sono state analizzate, il che significa che sono state confermate tramite un successivo avviso ufficiale o verificate direttamente tramite cambio di codice. Di queste:
- 5.138 si sono rivelate vere vulnerabilità.
- 231 non si sono rivelate vulnerabilità (falsi positivi).
- 40 sono ancora in fase di discussione.
Questo fornisce un tasso di falsi positivi del 4,3% su tutte le rilevazioni analizzate.
Gli autori
Cassie Crossley
Autrice di Software Supply Chain Security (O’Reilly). Ex vicepresidente della sicurezza della catena di fornitura presso Schneider Electric (un’azienda globale da 38 miliardi di euro), dove ha guidato programmi di sicurezza dei prodotti e resilienza informatica in complesse catene di fornitura internazionali. Relatrice e autorità di fama internazionale in materia di gestione delle vulnerabilità, rischio di prodotto e conformità normativa UE. Membro del consiglio di amministrazione di Cybeats.
Valerio Mulas
Oltre 20 anni di esperienza in sicurezza, architettura cloud, DevOps e infrastrutture resilienti in ambienti regolamentati e mission-critical. Hoa creato e protetto sistemi di produzione su larga scala nei settori bancario e fintech utilizzando AWS, Kubernetes, IaC e automazione CI/CD. Guida la piattaforma tecnica di VulNow, traducendo una profonda competenza ingegneristica in un’intelligence predittiva scalabile sulle vulnerabilità.
Conclusioni
La cosa interessante della soluzione è che permette di mantenere le soluzioni al sicuro anche quando la CVE non viene pubblicata: di per sè questo fenomeno rischierebbe di lasciare il codice scoperto a vulnerabilità anche per mesi, se non peggio. D’altro canto la normativa impone di chiudere queste falle il prima possibile, di cui però si rischia di non avere visibilità perché, come detto, gli scanner non avendo la CVE non riescono ad individuare le vulnerabilità. È un passo importante verso una proattività fattiva e non solo teorica che potrebbe, oggettivamente, cambiare l’approccio all’uso e all’implementazione di codice rispetto a come si è fatto fino ad ora.
