Wikipedia

Database delle vulnerabilità

Un database delle vulnerabilità (vulnerability database, VDB) è una piattaforma finalizzata a raccogliere, mantenere e diffondere informazioni sulle vulnerabilità informatiche note. Il database, di norma, descrive la vulnerabilità identificata, valuta il potenziale impatto sui sistemi interessati ed eventuali procedure o aggiornamenti per mitigare il problema. Un VDB assegna un identificativo univoco a ogni singola vulnerabilità catalogata, come un numero (per esempio 123456) o una classificazione alfanumerica (per esempio VDB-2020-12345). Le informazioni contenute nel database possono essere rese disponibili tramite pagine web, applicazioni esterne o API. Un VDB potrebbe fornire le informazioni gratuitamente, a pagamento o con una combinazione di queste due modalità.

Storia modifica

Il primo database di vulnerabilità è stato il "Repaired Security Bugs in Multics", pubblicato il 7 febbraio 1973 da Jerome H. Saltzer. Ha descritto l'elenco come "una lista con tutti i modi conosciuti con cui un utente può violare o aggirare i meccanismi di protezione di Multics".[1] Inizialmente l'elenco venne reso in qualche modo privato, con l'intento di nascondere i dettagli delle vulnerabilità fino a quando non fossero state trovate soluzioni. L'elenco pubblico conteneva due vulnerabilità locali di privilege escalation e tre attacchi locali di denial of service.[1]

Esempi vulnerabilità dei database modifica

I principali database di vulnerabilità, come il database ISS X-Force, il database Symantec/SecurityFocus BID e l'Open Source Vulnerability Database (OSVDB) aggregano un'ampia gamma di vulnerabilità di pubblico dominio, tra cui Common Vulnerabilities and Exposures (CVE). Il principale scopo del CVE, gestito dalla Mitre Corporation, è quello di tentare di aggregare le vulnerabilità note attribuendone un identificativo univoco in formato standardizzato.[2] Molti database di vulnerabilità utilizzano le informazioni ricevute da CVE e approfondiscono la ricerca fornendo punteggi di pericolosità delle vulnerabilità, valutazioni d'impatto e i necessari metodi di risoluzione. In passato, i CVE erano fondamentali per collegare i database delle vulnerabilità così da condividere patch e soluzioni di sicurezza critiche per impedire ai pirati informatici di accedere a informazioni sensibili su sistemi riservati.[3] Il National Vulnerability Database (NVD), gestito dal National Institute of Standards and Technology (NIST), è gestito separatamente dal database CVE gestito dalla Mitre Corporation, ma raccoglie solo le informazioni sulle vulnerabilità del CVE. NVD funge da integrazione a questi dati, fornendo il punteggio di rischio Common Vulnerability Scoring System (CVSS) e i dati della Common Platform Enumeration (CPE).

L'Open Source Vulnerability Database (OSVDB) offre un indice accurato, tecnico e imparziale sulla sicurezza delle vulnerabilità. Il database completo cataloga oltre 121.000 vulnerabilità. L'OSVDB è stato fondato nell'agosto 2002 e lanciato nel marzo 2004. Inizialmente, le nuove vulnerabilità identificate venivano analizzate dai membri del progetto e le spiegazioni erano riportate sul loro sito web. Con il crescere della necessità del servizio, tuttavia, l'esigenza di personale dedicato ha portato alla nascita della Open Security Foundation (OSF), un'organizzazione no-profit fondata nel 2005 per fornire finanziamenti ai progetti di sicurezza e in primo luogo all'OSVDB L'OSVDB è stato chiuso nell'aprile 2016.[4]

Il National Vulnerability Database (NVD) statunitense è un database completo sulle vulnerabilità della sicurezza informatica creato nel 2005 che riporta i dati del CVE. Il NVD è uno strumento di riferimento primario per la sicurezza informatica, sia per i privati, sia per le industrie, fornendo risorse informative sulle attuali vulnerabilità. Il NVD contiene oltre 100.000 documenti. Analogamente all'OSVDB, l'NVD pubblica valutazioni di impatto e classifica il materiale in un indice per fornire agli utenti un sistema di ricerca intellegibile.[5] Altri Paesi dispongono di propri database di vulnerabilità, come il National Vulnerability Database cinese e il Data Security Threats Database russo.

Una varietà di società commerciali mantiene anche i propri database di vulnerabilità, offrendo ai clienti servizi che forniscono dati sulle vulnerabilità nuovi e aggiornati in formato leggibile dalla macchina e attraverso portali web. Gli esempi includono il portale DeepSight[6] di Symantec e il feed di dati sulle vulnerabilità, il gestore delle vulnerabilità di Secunia (acquistato da Flexera)[7] e il servizio di intelligence sulle vulnerabilità di Accenture[8] (precedentemente iDefense).

I database delle vulnerabilità raccomandano alle aziende di sviluppare, classificare ed eseguire patch o altre misure correttive che tentino di correggere le vulnerabilità critiche. Tuttavia, questo può spesso portare alla creazione di ulteriori potenziali vulnerabilità, poiché le patch vengono create frettolosamente per impedire ulteriori sfruttamenti e violazioni dei sistemi. A seconda del livello di competenza di un utente o di un'azienda, è necessario garantire un accesso appropriato a un database delle vulnerabilità che fornisca indicazioni sulle vulnerabilità note che possono riguardare l'utente stesso. La giustificazione per limitare l'accesso ai singoli individui è quella di impedire ai pirati informatici di conoscere le vulnerabilità dei sistemi aziendali che potrebbero essere sfruttate ulteriormente.[9]

Utilizzo delle vulnerabilità dei database modifica

I database delle vulnerabilità contengono una vasta gamma di vulnerabilità identificate. Tuttavia, poche organizzazioni possiedono l'esperienza, il personale e il tempo per rivedere e porre rimedio a tutte le potenziali vulnerabilità del sistema, pertanto il punteggio di vulnerabilità è un metodo per determinare quantitativamente la gravità di una violazione del sistema. Esiste una moltitudine di metodi di punteggio nei database di vulnerabilità come US-CERT e la Critical Vulnerability Analysis Scale del SANS Institute, ma il Common Vulnerability Scoring System (CVSS) è la tecnica prevalente per la maggior parte dei database di vulnerabilità tra cui OSVDB, vFeed[10] e NVD. Il CVSS si basa su tre metriche principali: base, temporale e ambientale, ciascuna delle quali fornisce un punteggio di vulnerabilità.[11]

Base modifica

Questa metrica riguarda le proprietà immutabili di una vulnerabilità, come l'impatto potenziale dell'esposizione di informazioni riservate, l'accessibilità delle informazioni e le conseguenze della cancellazione irreversibile delle informazioni.

Temporale modifica

Le metriche temporali esprimono la natura mutevole di una vulnerabilità, come la credibilità di un exploit, lo stato attuale di una violazione del sistema e lo sviluppo di eventuali procedure di correzione che potrebbero essere applicate.[12]

Ambientale modifica

Questo aspetto del CVSS valuta le potenziali perdite subite da individui o organizzazioni in seguito a una vulnerabilità. Descrive, inoltre, l'obiettivo principale di una vulnerabilità, dai dispositivi privati alle grandi imprese, e il numero di persone potenzialmente coinvolte.[13]

Lo svantaggio derivante dall'utilizzo di diversi sistemi di punteggio è che non vi è accordo sulla gravità di una vulnerabilità e, di conseguenza, le diverse organizzazioni possono trascurare gli exploit critici del sistema. Uno dei principali vantaggi offerti da un sistema di punteggio standardizzato come il CVSS, invece, è che i punteggi delle vulnerabilità resi pubblici possono essere valutati, monitorati e risolti in tempi rapidi. Sia le organizzazioni, sia i singoli individui possono determinare l'impatto diretto di una vulnerabilità sul proprio sistema. I benefici derivanti dai database delle vulnerabilità per i privati e per le organizzazioni sono enormi, poiché i sistemi informatici sono sempre più integrati, cresce la nostra dipendenza e il nostro affidamento su di essi, così come cresce l'opportunità di sfruttamento dei dati.[14]

Falle di sicurezza più comuni tra le vulnerabilità dei database modifica

Errore nell'installazione iniziale modifica

Sebbene la funzionalità di un database possa apparire ineccepibile, in assenza di verifiche rigorose, i difetti più evidenti possono consentire ai pirati informatici di violare la sicurezza informatica di un sistema. Spesso i database vengono creati senza rigorosi controlli di sicurezza rendendo così il materiale sensibile di facile accesso.[15]

SQL Injection modifica

Gli attacchi ai database sono la forma più ricorrente di violazione della sicurezza informatica registrata nei database di vulnerabilità. Le SQL e NoSQL injections penetrano rispettivamente nei sistemi informatici tradizionali e nelle piattaforme di big data introducendo istruzioni malevole che consentono ai pirati informatici un accesso di sistema senza limiti.[16]

Database mal configurati modifica

I database tradizionali, di norma, evitano di implementare le patch principali suggerite dai database delle vulnerabilità per via dell'eccessivo carico di lavoro e della necessità di effettuare verifiche approfondite per garantire che le patch aggiornino le vulnerabilità del sistema difettoso. I responsabili delle banche dati concentrano i loro sforzi sulle principali carenze del sistema, offrendo così ai pirati informatici l'accesso non autorizzato al sistema grazie alle patch trascurate.[17]

Controlli carenti modifica

Tutti i database richiedono un sistema di revisione per documentare le modifiche o gli accessi ai dati. Quando i sistemi vengono sviluppati senza il necessario sistema di revisione, lo sfruttamento delle vulnerabilità del sistema è difficile da identificare e rimuovere. I database di vulnerabilità promuovono l'importanza del monitoraggio delle verifiche come deterrente per gli attacchi informatici.[18]

La protezione dei dati è fondamentale per qualsiasi azienda, poiché le informazioni private e finanziarie sono un bene prezioso e la loro sottrazione può compromettere la reputazione di un'azienda. L'implementazione di strategie di protezione dei dati è indispensabile per tutelare le informazioni riservate. Secondo alcuni, è l'apatia iniziale dei progettisti di software a rendere necessaria l'esistenza di database di vulnerabilità. Se i sistemi fossero progettati con maggiore diligenza, potrebbero essere impenetrabili dalle SQL e NoSQL injection, rendendo superflui i database di vulnerabilità.[19]

Note modifica

  1. ^ a b Saltzer, J. H., Repaired SEcurity Bugs in Multics (PDF), 7 febbraio 1973. URL consultato il 26 maggio 2023.
  2. ^ CVE Numbering Authorities, su cve.org. URL consultato il 26 maggio 2023.
  3. ^ Gu Yun-hua e Li Pei, Design and Research on Vulnerability Database, in 2010 Third International Conference on Information and Computing, vol. 2, 2010-06, pp. 209–212, DOI:10.1109/ICIC.2010.147. URL consultato il 26 maggio 2023.
  4. ^ (EN) Eduard Kovacs, OSVDB Shut Down Permanently, su SecurityWeek, 7 aprile 2016. URL consultato il 26 maggio 2023.
  5. ^ NVD - Home, su nvd.nist.gov. URL consultato il 26 maggio 2023.
  6. ^ (EN) Support and Services, su broadcom.com. URL consultato il 26 maggio 2023.
  7. ^ (EN) Software Vulnerability Management | Flexera, su flexera.com. URL consultato il 26 maggio 2023.
  8. ^ (EN) Accenture | Let There Be Change (PDF), su accenture.com. URL consultato il 26 maggio 2023.
  9. ^ Jon Erickson e Jon Erickson, Hacking: die Kunst des Exploits, Deutsche Ausgabe der 2., amerikanischen Auflage, 8., korrigierter Nachdruck, dpunkt.verlag, 2017, ISBN 978-1-59327-144-2.
  10. ^ (EN) vFeed, Inc. – Correlated Vulnerability Intelligence as A Service & Threat Intelligence Database., su vfeed.io. URL consultato il 26 maggio 2023.
  11. ^ Common Vulnerability Scoring System SIG, su FIRST — Forum of Incident Response and Security Teams. URL consultato il 26 maggio 2023.
  12. ^ Peter Mell, Karen Scarfone e Sasha Romanosky, Common Vulnerability Scoring System, in IEEE Security & Privacy, vol. 4, n. 6, 2006-11, pp. 85–89, DOI:10.1109/MSP.2006.145. URL consultato il 26 maggio 2023.
  13. ^ Lance Hayden, IT Security Metrics: A Practical Framework for Measuring Security & Protecting Data, 1ª ed., McGraw Hill Professional, ISBN 9780071713412.
  14. ^ (EN) Peter Mell, Sasha Romanosky e Karen Scarfone, Common Vulnerability Scoring System (PDF), in IEEE Security & Privacy, vol. 4, n. 6, novembre 2006, pp. 85-88.
  15. ^ Top 5 Database Security Threats (PDF), su imperva.com. URL consultato il 26 maggio 2023.
  16. ^ (EN) Kanchana Natarajan e Sarala Subramani, Generation of Sql-injection Free Secure Algorithm to Detect and Prevent Sql-Injection Attacks, in Procedia Technology, vol. 4, 2012, pp. 790–796, DOI:10.1016/j.protcy.2012.05.129. URL consultato il 26 maggio 2023.
  17. ^ (EN) Vulnerability Database Tops 1000 Flaws, in Network Security, vol. 2001, n. 6, 2001-06, p. 6, DOI:10.1016/S1353-4858(01)00616-X. URL consultato il 26 maggio 2023.
  18. ^ Hassan A. Afyouni, Database security and auditing: protecting data integrity and accessibility, 1ª ed., Thomson Course Technology, 2006, ISBN 978-0-619-21559-0.
  19. ^ M. N. Sirohi, Transformational dimensions of cyber crime, Alpha Editions, 2015, pp. 54-65, ISBN 978-81-931422-3-3.

Voci correlate modifica

Estratto da "https://it.wikipedia.org/w/index.php?title=Database_delle_vulnerabilità&oldid=138782460"