Crisi del sistema CVE: cosa significa per la cybersecurity della tua PMI e come difendersi

Il 16 aprile scorso, il mondo della cybersecurity ha trattenuto il respiro: una delle sue infrastrutture informative più critiche, il sistema CVE, rischiava di scomparire. L'allarme, fortunatamente rientrato nel giro di poche ore, ci ha concesso una tregua di circa undici mesi, ma ha sollevato interrogativi profondi sulla stabilità di meccanismi che diamo per scontati. Ma cosa ha scatenato questo panico e, soprattutto, cosa significa per la tua PMI? Tutto ha origine da una comunicazione del vicedirettore di MITRE, l'organizzazione no-profit finanziata dal governo americano che gestisce, tra gli altri, il framework CVE per la catalogazione standardizzata delle vulnerabilità software. La lettera annunciava una sospensione imminente dei fondi governativi, ipotizzando addirittura un'interruzione del servizio con conseguenze gravissime: dal deterioramento del National Vulnerability Database (NVD) alle difficoltà nelle operazioni di incident response e, in generale, per la sicurezza delle infrastrutture critiche.

Come consulente cyber security con esperienza specifica su infrastrutture complesse, basate su tecnologie come Laravel, Symfony, Docker e sistemi Linux (Debian, Ubuntu), ritengo fondamentale che le PMI comprendano la portata di questi eventi. La capacità di identificare, valutare e mitigare le vulnerabilità è al cuore di qualsiasi strategia di sicurezza efficace, specialmente con l'avvento di normative stringenti come la Direttiva NIS2.

Stai cercando un Consulente Cyber Security esperto per la tua Azienda? Nel mio profilo professionale trovi la mia esperienza e le competenze specifiche per aiutarti a proteggere il tuo business. Contattami per una consulenza.

MITRE e la nascita del sistema CVE: una necessità pratica

Per capire l'importanza del CVE, facciamo un passo indietro. MITRE (Massachusetts Institute of Technology Research and Engineering) nasce nel 1958 da un laboratorio del MIT, con il patrocinio dell'Air Force statunitense, con la missione di connettere la ricerca accademica con l'industria civile e militare. Inizialmente focalizzata sulla ricerca radar, l'organizzazione ha presto ampliato i suoi orizzonti includendo la cybersecurity. Curiosamente, mitre.org è stato il primo dominio .org registrato, il 1° gennaio 1985.

Nel 1999, MITRE pubblicò un paper proponendo un sistema per aggregare i dati provenienti da molteplici database di vulnerabilità software. L'idea scaturì da un'esigenza pratica: utilizzando diversi sistemi di Intrusion Detection (IDS), si resero conto della difficoltà nel capire se più strumenti stessero segnalando la medesima vulnerabilità o falle distinte. Ogni produttore, infatti, utilizzava convenzioni diverse per identificare le vulnerabilità, causando un'enorme perdita di tempo nel confrontare gli output.

Il sistema CVE (Common Vulnerabilities and Exposures) nasce quindi per dare un nome univoco e standardizzato a ogni vulnerabilità nota, risolvendo il problema dell'ambiguità e facilitando la correlazione delle informazioni tra diversi strumenti e fonti.

Ogni record CVE identifica una singola vulnerabilità e ne elenca le proprietà essenziali:

• Identificativo Unico (CVE ID): nel formato CVE-YYYY-NNNNN, dove YYYY è l'anno di pubblicazione e NNNNN un numero progressivo.
• Descrizione: un breve riassunto della natura della vulnerabilità.
• Riferimenti: link a report originali, patch, avvisi di sicurezza e altre risorse esterne.
• Punteggio di Severità (CVSS Score): un valore numerico che ne indica la gravità, come vedremo più avanti.

La prima lista pubblica conteneva appena 321 CVE, ma il numero è cresciuto esponenzialmente, superando le 40.000 vulnerabilità segnalate solo nel 2024. Questa crescita riflette sia l'aumento della superficie d'attacco del software moderno (applicazioni PHP legacy, complessi framework come Laravel o Symfony, infrastrutture cloud gestite con Docker e Kubernetes) sia la maggiore attenzione della comunità di sicurezza.

Vulnerabilità pubbliche: un'arma a doppio taglio o una necessità?

A questo punto, è lecito chiedersi se rendere pubblico un database con migliaia di vulnerabilità, facilmente interrogabile, sia una buona idea. Indubbiamente, può rendere i sistemi non aggiornati dei bersagli facili. Tuttavia, mantenere segrete queste informazioni rischierebbe un impatto ancora peggiore:

• Diffusione Inconsapevole: specialmente quando una vulnerabilità affligge una libreria o un componente (MySQL, PostgreSQL, Redis, o una dipendenza Composer in un progetto PHP) utilizzato da molti altri progetti, la mancanza di un identificativo standard renderebbe quasi impossibile per gli sviluppatori capire se sono affetti.
• Falsa Sicurezza: alcune aziende, purtroppo, potrebbero essere tentate di nascondere le vulnerabilità per timore di danni reputazionali. Questo comportamento instillerebbe un falso senso di sicurezza negli utenti, che potrebbero continuare a utilizzare versioni obsolete e vulnerabili del software.
• Mancanza di Apprendimento: l'analisi delle vulnerabilità passate è fondamentale per comprendere le minacce future, migliorare gli strumenti di rilevamento automatico e formare sviluppatori software e backend architect sulle best practice di sviluppo sicuro.

Come consulente web che si occupa quotidianamente di sicurezza informatica, posso affermare che la trasparenza, seppur con i suoi rischi, è preferibile. Permette una risposta più rapida e coordinata da parte della comunità e spinge i produttori a rilasciare patch tempestivamente.

Il percorso di una vulnerabilità: dallo Zero-Day alla pubblicazione CVE

Quando una vulnerabilità viene scoperta, è inizialmente definita zero-day, ovvero sconosciuta alla maggior parte degli attori, incluso il produttore del software. Il suo destino dipende da chi l'ha scoperta:

• Attaccante Malevolo: potrebbe sfruttarla direttamente o venderla nel dark web o a vulnerability broker. In questi casi, la falla potrebbe essere identificata solo a seguito di un attacco informatico, come avvenne per Log4Shell (CVE-2021-44228) nel 2021, segnalata ad Apache dalla squadra di sicurezza di Alibaba.
• Ethical Hacker o Ricercatore di Sicurezza: segnalerà responsabilmente la vulnerabilità al produttore o al maintainer del progetto, permettendo loro di sviluppare una correzione. I canali di segnalazione sono molteplici:
  • Contatto Diretto: via email a indirizzi dedicati (es. [email protected] per il kernel Linux) o tramite form specifici.
  • Piattaforme di Bug Bounty: siti come HackerOne o Bugcrowd offrono ricompense economiche a chi segnala bug di sicurezza, incentivando la divulgazione responsabile. Aziende come Google e Meta gestiscono anche propri programmi di Bug Bounty.
  • Vulnerability Broker (Mercato Grigio): entità come la (ormai ex) Zerodium o la (tuttora attiva) Crowdfense acquisiscono exploit per vulnerabilità non ancora pubbliche, pagando cifre significativamente più alte dei programmi di Bug Bounty (Zerodium nel 2019 pagava fino a 500.000 dollari per un RCE su un server; Crowdfense offre fino a 5 milioni di dollari per exploit mobile zero-click). Le vulnerabilità vendute a questi broker possono rimanere segrete per anni, o per sempre, se usate in attacchi mirati.

Indipendentemente dal metodo di segnalazione iniziale, l'assegnazione di un CVE ID avviene tramite una CNA (CVE Numbering Authority). Si tratta di organizzazioni autorizzate da MITRE a distribuire identificativi CVE per le vulnerabilità scoperte nei prodotti di loro competenza o segnalate loro. Esistono oltre 450 CNA attive, tra cui le piattaforme di Bug Bounty, aziende (Canonical, Google, Microsoft), e organizzazioni open source (kernel.org, Fedora Project). Alcune CNA, definite Root o Top-Level Root, hanno anche il compito di amministrare altre CNA sottostanti.

MITRE quindi mantiene la lista delle CNA, fornisce loro le credenziali per pubblicare su cve.org (ora cve.mitre.org) e verifica che le pubblicazioni rispettino le linee guida.

Il ruolo di un contractor IT esperto per le PMI diventa cruciale: non solo per implementare soluzioni tecniche, ma per interpretare il panorama delle minacce, valutare l'impatto delle vulnerabilità (anche quelle senza CVE immediato) e definire strategie di mitigazione. La mia esperienza pregressa mi ha insegnato quanto sia vitale questo aspetto.

NVD, CVSS e CWE: arricchire i dati sulle vulnerabilità

La lista di CVE pubblicata da MITRE è una base di partenza. Viene utilizzata per costruire altri database più ricchi, come il National Vulnerability Database (NVD), gestito anch'esso dal governo USA. L'NVD arricchisce i dati CVE con:

• Informazioni aggiuntive (link, dettagli tecnici).
• Analisi dell'impatto.
• Un valore più affidabile per il punteggio CVSS (Common Vulnerability Scoring System).

Il CVSS è uno standard industriale per valutare la severità delle vulnerabilità, assegnando un punteggio da 0 a 10. Questo punteggio, inizialmente proposto dalla CNA, viene spesso ricalcolato dall'NVD, a volte con variazioni significative. Il CVSS considera fattori come:

• Complessità dell'Attacco: quanto è facile sfruttare la falla?
• Privilegi Richiesti: l'attaccante necessita di privilegi particolari?
• Interazione Utente: è richiesta un'azione da parte della vittima?
• Impatto: quali sono le conseguenze su Confidenzialità, Integrità e Disponibilità dei dati (la triade CIA)?

Ad esempio, Log4Shell, che permetteva a un utente anonimo l'esecuzione di codice arbitrario con estrema facilità, ricevette un CVSS di 10.0. Meltdown (CVE-2017-5754), una grave falla hardware nei processori, ottenne "solo" 5.6, poiché la sua exploitation non è banale e impatta principalmente la confidenzialità.

L'NVD è il punto di riferimento per la maggior parte degli strumenti automatici di rilevamento delle vulnerabilità. Senza un coordinatore centrale come MITRE, l'assegnazione di nuovi CVE ID sarebbe caotica, e questi strumenti (così come antivirus e software di difesa attiva) ne soffrirebbero enormemente.

Un altro sistema importante, anch'esso gestito da MITRE con gli stessi fondi a rischio, è il CWE (Common Weakness Enumeration). Il CWE è un sistema di classificazione per i tipi di difetti software che possono portare a vulnerabilità (es. SQL Injection è CWE-89, Cross-Site Scripting è CWE-79). È uno strumento prezioso per sviluppatori e analisti per comprendere le cause radice delle falle di sicurezza.

La crisi di aprile e le alternative al sistema CVE

Torniamo al 16 aprile. Poche ore dopo la lettera di MITRE, è stata annunciata la creazione della CVE Foundation, con l'obiettivo di portare avanti il lavoro in caso di interruzione dei finanziamenti governativi. L'iniziativa, partita da alcuni membri del board CVE, era apparentemente in cantiere da un anno, come un piano di emergenza. Le preoccupazioni espresse riguardavano la sostenibilità e la neutralità di una risorsa globale dipendente da un singolo sponsor governativo. I dettagli sul finanziamento della fondazione non sono ancora chiari.

Fortunatamente, l'agenzia federale USA per la cybersecurity (CISA) ha annunciato il rinnovo del contratto con MITRE per altri 11 mesi, garantendo la continuità del programma CVE e dando tempo per una transizione.

Questa vicenda ha però evidenziato la fragilità di un sistema dato per assodato. Sono state proposte alternative:

• GCVE (Global CVE Allocation System): proposto dal Cyber Incident Response Center del Lussemburgo (CIRCL), è un approccio decentralizzato. Ogni autorità (GNA - GCVE Numbering Authority) può assegnare i propri identificativi in modo indipendente, aggiungendo un prefisso dell'autorità emittente al codice della vulnerabilità (es. GCVE-<GNA_ID>-YYYY-NNNNN). GNA 0 garantirebbe la retrocompatibilità con i CVE storici (es. CVE-2017-5754 diventerebbe GCVE-0-2017-5754). Tuttavia, anche questo sistema necessita di un ente centrale (il CIRCL) per registrare le GNA.
• EUVD (European Vulnerability Database): un'iniziativa dell'Unione Europea, il cui sviluppo sembra essere iniziato nel giugno dell'anno precedente, ma il cui portale beta è emerso solo di recente.

Il rischio concreto è una frammentazione che renderebbe nuovamente difficile identificare univocamente una vulnerabilità, vanificando lo scopo originale del CVE. E in tutto questo, il sistema CWE, pur meno critico dei CVE, sembra essere stato dimenticato.

Implicazioni per le PMI e strategie di difesa

Dopo 25 anni, il progetto CVE mostra i suoi limiti. Forse avremmo dovuto capire prima che basare l'intera infrastruttura di cybersecurity globale su un ente finanziato da un singolo governo non era saggio. Questa "doccia fredda" potrebbe insegnarci a pianificare meglio per il futuro.

Per una PMI italiana, questa situazione di incertezza si traduce in potenziali rischi:

• Ritardi nelle Informazioni: se il sistema CVE dovesse subire interruzioni o frammentarsi, le informazioni sulle nuove vulnerabilità potrebbero arrivare in ritardo o in modo disorganizzato.
• Inefficacia degli Strumenti Automatici: gli scanner di vulnerabilità e gli strumenti di patch management potrebbero diventare meno affidabili.
• Difficoltà di Compliance: normative come la Direttiva NIS2 e il GDPR richiedono una gestione proattiva delle vulnerabilità. Un sistema CVE inefficiente complica l'aderenza a questi obblighi. La Direttiva NIS2, in particolare, impone misure tecniche, operative e organizzative rigorose, come discusso in NIS2: Obblighi, Scadenze e Strategie per la Sicurezza Aziendale.

Cosa può fare, dunque, una PMI?

• Mantenere un Inventario Software Aggiornato: sapere quali software e librerie (PHP, Laravel, Symfony, MySQL, PostgreSQL, Redis, Docker, sistemi Debian/Ubuntu) sono in uso è il primo passo.
• Adottare un Processo di Patch Management Robusto: non aspettare le segnalazioni, ma cercare attivamente gli aggiornamenti e applicarli con priorità basata sul rischio (il CVSS aiuta in questo).
• Diversificare le Fonti di Informazione: oltre all'NVD, monitorare le mailing list di settore, i security advisory dei produttori e i feed di intelligence sulle minacce.
• Investire in Competenze Interne o Esterne: la figura del Responsabile IT o del Responsabile della Sicurezza Informatica è cruciale. Dove non presente internamente, affidarsi a un consulente cyber security esperto diventa indispensabile. Un professionista come me può aiutare a interpretare i dati, prioritizzare gli interventi e implementare una strategia di vulnerability management su misura. Contattami per una consulenza per capire come proteggere al meglio il tuo business.
• Non Sottovalutare la Formazione (Security Awareness Training): un personale consapevole è la prima linea di difesa.
• Preparare Piani di Incident Response e Disaster Recovery: essere pronti a reagire in caso di incidente.

La situazione attuale del sistema CVE è un monito: la cybersecurity è un campo dinamico e nessuna infrastruttura, per quanto consolidata, è immune da crisi. Le PMI devono essere agili e proattive, supportate da partner tecnologici che, come me, vedono la consulenza non come un semplice intervento tecnico, ma come una partnership strategica per la resilienza e la crescita, come spiego in Consulente Cyber Security a Torino.