Security: la divulgazione coordinata delle vulnerabilità è un bene per tutti

Divulgare o non divulgare le vulnerabilità software? È un tema di stretta attualità che in passato ha trovato molti esperti schierati su fronti diversi. Per fare ulteriore chiarezza, Veracode, fornitore leader di test per la sicurezza delle applicazioni (AST), ha rilasciato i risultati di uno studio globale sul tema della divulgazione delle vulnerabilità software, denominato "Exploring Coordinated Disclosure", che ha analizzato comportamenti, politiche e aspettative associate alle modalità in cui organizzazioni e ricercatori di sicurezza esterni collaborano in caso di identificazione di vulnerabilità.

Dallo studio emerge che oggi le aziende di software e i ricercatori di sicurezza sono quasi universalmente d'accordo nel pensare che rivelare le vulnerabilità per migliorare la sicurezza software rappresenti un vantaggio per tutti. Il 90% dei rispondenti, infatti, ha confermato che la divulgazione di vulnerabilità "ha universalmente lo scopo più ampio di migliorare il modo in cui il software viene sviluppato, utilizzato e corretto". Riconoscere che le vulnerabilità non affrontate determinino l'enorme rischio di conseguenze negative per gli interessi di imprese, consumatori e persino per la stabilità economica globale, rappresenta un punto di svolta nell'industria software.
"L'allineamento che lo studio rivela è molto positivo", ha affermato Chris Wysopal, Chief Technology Officer and co-founder di Veracode. "La sfida, tuttavia, è che le politiche di divulgazione delle vulnerabilità sono estremamente incoerenti. Se i ricercatori non sono sicuri di come procedere quando rilevano una vulnerabilità, le organizzazioni rimangono esposte a minacce della sicurezza, dando ai criminali la possibilità di sfruttare queste vulnerabilità. Sebbene oggi disponiamo di strumenti e processi per trovare e ridurre il numero di bug nel software durante il processo di sviluppo ogni giorno vengono scoperte nuove vulnerabilità.

Una solida politica di divulgazione rappresenta un elemento chiave indispensabile della strategia di sicurezza di un'organizzazione e consente ai ricercatori di lavorare con l'azienda stessa per ridurne l'esposizione. Una buona politica di divulgazione delle vulnerabilità definirà le procedure per lavorare con i ricercatori di sicurezza esterni, stabilirà le aspettative su tempistiche e risultati fissi, oltre a individuare i difetti e correggere i software prima che vengano distribuiti".

Lo studio rivela anche arti spunti interessanti. Vediamo i principali.
a) Le divulgazioni di vulnerabilità non richieste avvengono regolarmente. L'indagine ha rilevato che negli ultimi 12 mesi oltre un terzo delle aziende ha ricevuto un report di divulgazione delle vulnerabilità non richiesto. Ciò rappresenta un'opportunità per collaborare con la parte che si occupa della segnalazione per correggere le vulnerabilità e quindi divulgarle, migliorando così la sicurezza generale. Per le organizzazioni che hanno ricevuto un rapporto di vulnerabilità non richiesto, il 90% delle vulnerabilità sono state divulgate in modo coordinato tra i ricercatori di sicurezza e l'azienda. Questa è la prova di un cambiamento significativo nella mentalità a dimostrazione che lavorare in modo collaborativo è l'approccio più efficace per raggiungere la trasparenza e migliorare la sicurezza.

b) I ricercatori di sicurezza sono motivati dal bene comune. Lo studio mostra che i ricercatori di sicurezza sono generalmente ragionevoli e motivati dal desiderio di migliorare la sicurezza per il bene comune. Il 57% dei ricercatori si aspetta che gli venga comunicato quando una vulnerabilità è stata riparata, mentre il 47% si aspetta aggiornamenti regolari sulla correzione e il 37% si aspetta di convalidare la correzione. Solo il 18% degli intervistati si aspetta di essere pagato e il 16% si aspetta il riconoscimento della propria scoperta.
c) Le aziende collaboreranno per risolvere i problemi. In modo promettente, tre aziende su quattro dichiarano di disporre di un metodo consolidato per ricevere un report da un ricercatore di sicurezza e il 71% degli sviluppatori ritiene che i ricercatori di sicurezza dovrebbero essere in grado di eseguire test non richiesti. Ciò potrebbe sembrare un controsenso poiché gli sviluppatori sarebbero maggiormente colpiti dall'interruzione del flusso di lavoro per effettuare una correzione di emergenza. Tuttavia i dati mostrano che gli sviluppatori vedono la divulgazione coordinata come parte del loro processo di sviluppo sicuro, si aspettano che il proprio lavoro venga testato al di fuori dell'organizzazione e sono pronti per rispondere ai problemi identificati.

d) Non sempre le aspettative dei ricercatori di sicurezza in merito ai tempi di riparazione sono realistiche. I dati mostrano che dopo aver segnalato una vulnerabilità il 65% dei ricercatori di sicurezza si aspetta una correzione in meno di 60 giorni. Questo lasso temporale potrebbe essere troppo impellente e persino irrealistico se confrontato con il report più recente Veracode State of Software Security, che ha rilevato che oltre il 70% di tutte le falle rimane per un mese dopo la scoperta. Per tre mesi quasi il 55%. Inoltre, dallo studio emerge che le organizzazioni sono impegnate a correggere e divulgare in modo responsabile le falle e, contestualmente, devono avere un tempo ragionevole per farlo.
e) I bug bounty non sono una panacea. Secondo la ricerca sebbene i programmi di bug bounty siano al centro dell'attenzione quando si parla di divulgazione, sembra che in realtà il richiamo di un giorno di paga non stia guidando il grosso delle divulgazioni. Infatti, quasi la metà (47%) delle organizzazioni ha implementato programmi di bug bounty, ma solo il 19% delle segnalazioni di vulnerabilità proviene da questi. Sebbene possano far parte di una strategia di sicurezza globale i bug bounty si rivelano spesso inefficienti e costosi. Dato che la maggior parte dei ricercatori di sicurezza è principalmente motivata dal vedere riparata una vulnerabilità piuttosto che dal denaro, le aziende dovrebbero considerare di concentrare le proprie risorse limitate sullo sviluppo di un software sicuro che trova le vulnerabilità all'interno del ciclo di vita dello sviluppo del software.