Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Alessandro Rugolo : 13 Giugno 2024 08:56
Come si valutano le vulnerabilità di sicurezza di un software? E’ possibile determinare la loro severità? Come si può stabilire l’ordine da utilizzare per procedere all’aggiornamento del codice in caso di vulnerabilità multiple?
Queste sono solo alcune delle domande che ci si deve porre quando si gestisce la sicurezza di un sistema informatico. Una delle possibili soluzioni passa per una organizzazione chiamata FIRST (Forum of Incident Response and Security Teams) e per uno strumento conosciuto con l’acronimo di CVSS ovvero Common Vulnerability Scoring System, ormai giunto alla versione 4.0.
La storia del CVSS si deve fare risalire al 2005 quando dopo circa due anni di studi e ricerche il National Infrastructure Advisory Council, organo consultivo del presidente degli Stati Uniti d’America, lanciò la versione 1.0. Seguirono la versione 2.0 del 2007 e la 3.0 del 2015. Il 21 ottobre 2023 è stata rilasciata la versione attuale, la 4.0.
Vuoi diventare un Ethical Hacker?
Non perdere i nostri corsi e scrivi subito su WhatsApp al numero
375 593 1011
per richiedere informazioni dicendo che hai trovato il numero sulle pagine di Red Hot Cyber
Supporta RHC attraverso:
Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.
CVSS è uno standard tecnico molto utile ma, come tutte le cose non risolve ogni genere di problema, per esempio non fornisce la misura della probabilità di quanto una vulnerabilità possa essere sfruttata da un attaccante, questo perchè essa non è determinata esclusivamente da fattori tecnici.
CVSS consiste nella assegnazione di un punteggio tra 0 e 10 ad ogni vulnerabilità identificata, il punteggio indica la gravità della vulnerabilità che é tanto maggiore quanto più alto è il punteggio.
L’assegnazione del punteggio si effettua valutando 30 diversi fattori, che per comodità e omogeneità sono raggruppati in quattro categorie: Base, Threat, Environmental, Supplemental, che sono abbreviati in B,T,E ed S. Perciò quando si parla di CVSS-B si intende il valore CVSS calcolato utilizzando solo le metriche Base e ciò accade nella maggior parte dei casi.
La categoria (o metrica) Base contiene a sua volta altre due metriche: Exploitability e Impact. Exploitability comprende quelle metriche che valutano i requisiti per sfruttare con successo la vulnerabilità. Impact invece comprende le metriche utili a misurare l’impatto della vulnerabilità in oggetto sulla triade CIA (Confidentiality, Integrity, Availability).
Come detto, oltre alle metriche Base esistono altre tre categorie:
Naturalmente il CVSS 4.0 ha tante altre interessanti caratteristiche che i più curiosi potranno trovare in questo studio di Davide Ariu: About the Common Vulnerability Scoring System (CVSS) 4.0
Provare a calcolare il valore a partire da una vulnerabilità nota è relativamente semplice impiegando l’apposito calcolatore online fornito sempre da FIRST. Fare qualche prova permette di rendersi effettivamente conto del livello di dettaglio dato da CVSS e capire quanto il valore reale dipenda effettivamente dalla specificità dell’organizzazione presa in considerazione.
Con quanto detto finora abbiamo risposto in parte solo alla prima delle domande iniziali: come si valutano le vulnerabilità di sicurezza di un software. Per provare a rispondere alle altre due domande occorrono delle considerazioni sulla infrastruttura informatica in esame, sull’ambiente e sui rischi connessi. Considerazioni quindi legate al singolo caso e non generalizzabili.
Spesso nel corso dell’analisi delle vulnerabilità di un sistema informatico aziendale emergono decine o centinaia di vulnerabilità, alcune note, la maggior parte non note al team di sicurezza. Valutare il rischio legato ad ogni singola vulnerabilità e dare la giusta priorità per la loro risoluzione è il lavoro difficile.
Occorre inoltre considerare che questo processo è spesso frammentario e viene eseguito manualmente in quanto non è sempre possibile avere tutti i dati disponibili e visibili con un solo strumento ne è semplice riversarli in un unico contenitore per poterli analizzare. Un’ultima problematica, non la meno importante, riguarda la loro visualizzazione, che spesso comporta la creazione di grafici non di immediata lettura.
Esistono inoltre diversi problemi di natura pratica legati alla individuazione delle vulnerabilità e alla loro mitigazione. In alcuni ambienti non è possibile lanciare programmi automatici per la scansione dei sistemi, comportando la ricerca manuale nei singoli dispositivi. Non sempre i sistemi aziendali sono aggiornati e non sempre supportano le modifiche necessarie per mitigare le vulnerabilità note. In alcuni casi si potrebbe addirittura compromettere la funzionalità (leggasi operatività) del sistema e ciò non è normalmente gradito. In definitiva occorre trovare il giusto compromesso tra sicurezza e operatività.
A questo punto è importante notare che esistono anche metodi per la gestione della vulnerabilità sulla base del rischio specifico che corre una determinata azienda o organizzazione. Questo approccio tiene conto di informazioni relative alla vulnerabilità della parte in considerazione.
Per rispondere a queste nuove domande occorre prendere in considerazione un nuovo acronimo: CVE, che sta per “Common Vulnerabilities and Exposures”. Infatti CVE non è altro che una lista che comprende le vulnerabilità conosciute ed è pubblicata da MITRE.
Il MITRE mantiene anche aggiornato l’elenco delle CVE Numbering Authorities (CNA), ovvero delle organizzazioni autorizzate ad assegnare un numero ad una vulnerabilità e a pubblicarlo secondo una ben definita procedura. Queste CNA sono generalmente produttori di software e ricercatori di sicurezza ma chiunque può richieder di assegnare un numero ad una nuova vulnerabilità. Ogni CVE è composta da un numero identificatore, una breve descrizione e i riferimenti ai report della vulnerabilita.
L’elenco, nella versione attuale, comprende 233.151 diversi elementi.
Se avevate pensato che la parte più complicata fosse finita, vi siete sbagliati!
Non abbiamo ancora neanche tentato di rispondere alla domanda forse più importante: come si può stabilire l’ordine da utilizzare per procedere all’aggiornamento del codice in caso di vulnerabilità multiple?
Prioritizzare le vulnerabilità richiede infatti la perfetta conoscenza dell’organizzazione e l’assegnazione di un valore di rischio legato all’impatto sul core business dell’azienda. In definitiva alle vulnerabilità con valore di rischio più elevato deve corrispondere di massima un indice di priorità più elevato.
In questo articolo abbiamo visto alcuni concetti importanti che rispondono agli acronimi di CVSS e CVE ma anche alcuni processi di gestione della sicurezza come la gestione delle vulnerabilità anche nella forma del rischio specifico.
Il mio obiettivo era quello di far capire il livello di complessità di questi concetti e delle operazioni da compiere da parte del team di sicurezza informatica responsabile di gestire la sicurezza di una organizzazione.
Spero di esserci riuscito.
Alessandro Rugolo
Copyright @ 2003 – 2024 RED HOT CYBER
PIVA 16821691009