Contenuto
- Solo i fatti
- Nessun bug, nessuno stress: la tua guida passo passo alla creazione di software che ti cambia la vita senza distruggere la tua vita
- Contabilità per impatto?
- È ora di cambiare il sistema?
Fonte: BrianAJackson / iStockphoto
Porta via:
È tempo di scuotere le cose con il modo in cui pensiamo di valutare il rischio per i componenti open source.
Sviluppare un sistema per valutare quanto seriamente la comunità di sviluppo software dovrebbe prendere le vulnerabilità è una sfida, per dirla alla leggera. Il codice è scritto dagli umani e avrà sempre dei difetti. La domanda quindi, se assumiamo che nulla sarà mai perfetto, è come possiamo meglio classificare i componenti in base al loro rischio in un modo che ci permetta di continuare a lavorare in modo produttivo?
Solo i fatti
Mentre ci sono molti approcci diversi che si potrebbero adottare per affrontare questo problema, ognuno con la propria valida giustificazione, il metodo più comune sembra essere basato su un modello quantitativo.
Da un lato, l'utilizzo di un approccio quantitativo per giudicare la gravità di una vulnerabilità può essere utile in quanto è più obiettivo e misurabile, basato esclusivamente sui fattori correlati alla vulnerabilità stessa.
Questa metodologia esamina il tipo di danno che potrebbe verificarsi se la vulnerabilità venisse sfruttata, considerando quanto ampiamente utilizzato il componente, la libreria o il progetto viene utilizzato nell'industria del software, nonché fattori quali il tipo di accesso a cui potrebbe dare un utente malintenzionato il caos del relitto dovrebbe usarlo per violare il loro obiettivo. Fattori come la facile sfruttabilità potenziale possono svolgere un ruolo importante in questo aspetto nel punteggio. (Per ulteriori informazioni sulla sicurezza, consulta Cybersecurity: in che modo i nuovi progressi portano nuove minacce e viceversa.)
Se vogliamo guardare a un livello macro, la prospettiva quantitativa esamina come una vulnerabilità potrebbe danneggiare il gregge, concentrandosi meno sul danno che potrebbe cadere sulle aziende che sono effettivamente colpite dall'attacco.
Il National Vulnerability Database (NVD), forse il più noto database di vulnerabilità, adotta questo approccio per entrambe le versioni 2 e 3 del loro Common Vulnerability Scoring System (CVSS). Sulla loro pagina che spiega le loro metriche per la valutazione delle vulnerabilità, scrivono del loro metodo che:
Il suo modello quantitativo garantisce misurazioni accurate ripetibili, consentendo agli utenti di vedere le caratteristiche di vulnerabilità sottostanti utilizzate per generare i punteggi. Pertanto, CVSS è adatto come sistema di misurazione standard per industrie, organizzazioni e governi che necessitano di punteggi di impatto sulla vulnerabilità accurati e coerenti.
Sulla base dei fattori quantitativi in gioco, l'NVD è quindi in grado di ottenere un punteggio di gravità, sia con un numero sulla scala - da 1 a 10, con 10 che è il più grave - sia con le categorie LOW, MEDIUM e HIGH .
Nessun bug, nessuno stress: la tua guida passo passo alla creazione di software che ti cambia la vita senza distruggere la tua vita
Non puoi migliorare le tue capacità di programmazione quando a nessuno importa della qualità del software.
Contabilità per impatto?
Tuttavia, sembra che l'NVD stia facendo uno sforzo per evitare ciò che possiamo definire più una misura qualitativa di una vulnerabilità, basata sull'impatto che un certo exploit ha avuto nel causare danni. Ad essere onesti, incorporano l'impatto nella misura in cui misurano l'impatto della vulnerabilità sul sistema, esaminando i fattori di riservatezza, integrità e disponibilità. Questi sono tutti elementi importanti da considerare - come nel caso del vettore di accesso, della complessità dell'accesso e dell'autenticazione più facilmente misurabili - ma non si sentono all'altezza del compito di mettere in relazione l'impatto del mondo reale quando una vulnerabilità causa perdite reali a un'organizzazione.
Prendiamo, ad esempio, la violazione di Equifax che ha rivelato le informazioni di identificazione personale di circa 145 milioni di persone, inclusi i dettagli della patente di guida, i numeri di previdenza sociale e altri bit che potrebbero essere utilizzati da personaggi senza scrupoli per compiere operazioni fraudolente.
È stata la vulnerabilità (CVE-2017-5638) che è stata scoperta nel progetto Apache Struts 2 che Equifax ha usato nella loro app web che ha permesso agli aggressori di entrare dalla porta principale e alla fine uscire con le braccia piene di succose informazioni personali .
Mentre l'NVD ha giustamente assegnato un punteggio di gravità pari a 10 e ALTO, la loro decisione era dovuta alla loro valutazione quantitativa del suo potenziale danno e non è stata influenzata dall'ampio danno che si è verificato successivamente quando la violazione di Equifax è diventata pubblica.
Questa non è una svista da parte dell'NVD, ma parte della loro politica dichiarata.
L'NVD fornisce "punteggi di base" CVSS che rappresentano le caratteristiche innate di ciascuna vulnerabilità. Al momento non forniamo "punteggi temporali" (metriche che cambiano nel tempo a causa di eventi esterni alla vulnerabilità) o "punteggi ambientali" (punteggi personalizzati per riflettere l'impatto della vulnerabilità sulla tua organizzazione).
Per i decisori, il sistema di misurazione quantitativa dovrebbe essere meno importante poiché sta esaminando le possibilità che si diffondano danni in tutto il settore. Se sei il CSO di una banca, dovresti preoccuparti dell'impatto qualitativo che un exploit può avere se viene utilizzato per recuperare i dati dei tuoi clienti, o peggio, i loro soldi. (Scopri i diversi tipi di vulnerabilità in Le 5 minacce più spaventose della tecnologia.)
È ora di cambiare il sistema?
Quindi, se la vulnerabilità di Apache Strusts 2 utilizzata nel caso Equifax ricevesse un ranking più elevato alla luce dell'entità del danno che si è rivelato, o renderebbe il turno di essere troppo soggettivo per un sistema come l'NVD per continuate così?
Concediamo che fornire i dati necessari per ottenere un "punteggio ambientale" o "punteggio temporale" come descritto dall'NVD sarebbe estremamente difficile, aprendo i gestori del team CVSS libero a critiche incessanti e un sacco di lavoro per l'NVD e altri per l'aggiornamento dei loro database man mano che emergono nuove informazioni.
Vi è, naturalmente, la domanda su come un tale punteggio verrebbe compilato, poiché pochissime organizzazioni sono in grado di offrire i dati necessari sull'impatto di una violazione, a meno che non sia richiesto da una legge di divulgazione. Dal caso di Uber abbiamo visto che le aziende sono disposte a pagare rapidamente nella speranza di impedire alle informazioni che circondano una violazione di raggiungere la stampa per timore di affrontare un contraccolpo pubblico.
Forse ciò che è necessario è un nuovo sistema che potrebbe incorporare i buoni sforzi dei database delle vulnerabilità e aggiungere il proprio punteggio aggiuntivo quando le informazioni diventano disponibili.
Perché istigare questo ulteriore livello di punteggio quando il precedente sembra aver fatto abbastanza bene il suo lavoro in tutti questi anni?
Francamente, dipende dalle responsabilità delle organizzazioni assumersi la responsabilità delle loro applicazioni. In un mondo ideale, tutti dovrebbero controllare i punteggi dei componenti che usano nei loro prodotti prima di aggiungerli al loro inventario, ricevere avvisi quando vengono scoperte nuove vulnerabilità in progetti precedentemente ritenuti sicuri e implementare le patch necessarie da sole .
Forse se esistesse un elenco che mostra quanto devastanti potrebbero essere alcune di queste vulnerabilità per un'organizzazione, le organizzazioni potrebbero sentirsi più sotto pressione per non farsi prendere da componenti rischiosi. Per lo meno, potrebbero prendere delle misure per fare un vero inventario di quali librerie open source hanno già.
All'indomani del fiasco di Equifax, probabilmente più di un dirigente di livello C si stava arrampicando per assicurarsi che non avessero nei loro prodotti la versione vulnerabile di Struts. È un peccato che ci sia voluto un incidente di questa portata per spingere l'industria a prendere sul serio la propria sicurezza open source.
Speriamo che la lezione che le vulnerabilità nei componenti open source delle tue applicazioni possano avere conseguenze molto reali avrà un impatto sul modo in cui i responsabili delle decisioni danno la priorità alla sicurezza, scegliendo gli strumenti giusti per proteggere i loro prodotti e i dati dei clienti.