Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Massimiliano Brolli : 11 Febbraio 2022 07:20
Si parla spesso dell’approccio alla divulgazione responsabile delle vulnerabilità, ma come abbiamo già visto, molto spesso, tutto questo non avviene con una prassi ben regolamentata, sebbene ci siano diversi spunti a livello internazionale e best practices, anche in ambito ENISA.
Quindi è sicuro ed è corretto divulgare le vulnerabilità in modo responsabile, ed è importante farlo.
Questo consente di dare modo a tutta l’industria del software di migliorarsi, di migliorare tutti i prodotti di detection delle vulnerabilità pubbliche oltre che a rendere tutti partecipi del fatto che è necessaria una patch per uno specifico prodotto che risolve un pericoloso 0-day.
Sei un Esperto di Formazione?
Entra anche tu nel Partner program!
Accedi alla sezione riservata ai Creator sulla nostra Academy e scopri i vantaggi riservati ai membri del Partner program.
Per ulteriori informazioni, scrivici ad [email protected] oppure su Whatsapp al 379 163 8765
Supporta RHC attraverso:
Ma ancora oggi, molte aziende sono riluttanti ad attivare programmi di bug Bounty o responsabile disclosure e tendono sempre ad evitare quella che viene chiamata full disclosure (a valle della coordinated vulnerability disclosure), ovvero la pubblicazione completa dei payload relativi alla specifica vulnerabilità.
Questo spesso viene fatto emettendo patch senza dire nulla al mondo intero, che è stato risolto un pericoloso zeroday pensando che avere dei CVE pubblicati sul National vulnerability database (NVD) degli Stati uniti d’america, porti un danno in termini di brand reputetion e web reputetion.
Ma questo è un comportamento sbagliato in quanto non tutela la trasparenza verso i consumatori oltre a creare una chiusura e un aumento delle vulnerabilità non documente, dimenticando che questo è un diritto di tutti i clienti che acquistano un determinato pridotto hardware o software.
Non esistono software privi di vulnerabilità, anche con i migliori processi di sviluppo sicuro e quindi una attiva collaborazione con i ricercatori di bug, se ben gestita, consente invece di migliorare drasticamente la sicurezza dei prodotti, beneficiando entrambi (ricercatore e aziende) in eguale misura.
Tutte le grandi aziende dovrebbe disporre di una CNA (CVE Numbering Authority), ovvero essere in grado di assegnare autonomamente i CVE a seguito della scoperta di nuove falle di sicurezza divulgate in modo responsabile dai ricercatori di bug.
Questo è un percorso che non si attua dall’oggi al domani, ma è importante pensarci, soprattutto mi riferisco a chi sviluppa software e lo vende in un panorama internazionale.
Vi ricordate dell’inizio dell’emergenza da coronavirus e di quanto parlammo dei bug di zoom? Inizialmente l’azienda pensava che la sicurezza non era un valore abilitante, si parlo della finta crittografia e2e, di politiche di sicurezza non conformi, ma poi venne avviato un piano 90gg per rimettere in sesto la cyber posture aziendale con tanto di programma di bug bounty in hackerone e con l’acquisto dell’azienda di sicurezza Keybase specializzata nella crittografia dei dati.
Pensate che ci sono aziende che portano i loro prodotti a manifestazioni, dove lo scopo è ricercare vulnerabilità non classificate pagando i ricercatori per questo sforzo, oltre a regalare i prodotti stessi e poi emettere i CVE.
Parlo di Pwn2own, parlo ti Tesla, che regalò una Model 3 a dei ricercatori che avevano scoperto degli zeroday, ma anche di Microsoft, Apple, Google e tanti altri che hanno capito che collaborare attivamente con i ricercatori premia entrambi, in modo trasparente, oltre che a tutelare tutti i loro clienti.
Tutto questo è vero, è un percorso che non avviene dall’oggi al domani, ma solo le aziende che comprenderanno l’importanza dell’aiuto da parte della comunità hacker per migliorare i propri prodotti potranno avere successo, nel prossimo e difficile futuro.
Massimiliano Brolli