Tag Archivio per: CSAF 2.0

Greenbone AG

Greenbone Detection efficace anche durante l’interruzione NVD del NIST

Nonostante l’interruzione del NIST NVD, il sistema di rilevamento di Greenbone mantiene piena operatività, garantendo scansioni affidabili delle vulnerabilità senza dipendere dai dati di arricchimento CVE mancanti.

Dal 1999, il Common Vulnerabilities and Exposures (CVE), gestito dalla MITRE Corporation, fornisce gratuitamente informazioni pubbliche sulle vulnerabilità, pubblicando e aggiornando dati sulle falle del software. Dal 2005, il National Institute of Standards and Technology (NIST) ha arricchito questi rapporti CVE, dando maggiore contesto per migliorare la valutazione del rischio informatico. Tuttavia, all’inizio del 2024, la comunità della sicurezza informatica è stata sorpresa dall’interruzione delle attività del NIST National Vulnerability Database (NVD). A circa un anno di distanza, questa interruzione non è stata ancora completamente risolta [1][2]. Con il numero crescente di CVE segnalati ogni anno, le difficoltà del NIST hanno causato un ritardo significativo nell’assegnazione di contesti fondamentali come il punteggio di gravità (CVSS), gli elenchi di prodotti interessati (CPE) e le classificazioni delle debolezze (CWE).

I cambiamenti politici promossi di recente dall’amministrazione Trump hanno generato notevole incertezza riguardo al futuro della condivisione delle informazioni sulle vulnerabilità, influenzando anche numerosi fornitori di sicurezza che da tali dati dipendono. Parallelamente, il bilancio 2025  della Cybersecurity and Infrastructure Security Agency (CISA), riflette una significativa riduzione delle risorse in aree chiave. In particolare, si registra un taglio di circa 49,8 milioni di dollari destinati ad appalti, costruzioni e miglioramenti e una diminuzione di 4,7 milioni di dollari per attività di ricerca e sviluppo. Questi ridimensionamenti hanno spinto la CISA ad adottare misure di contenimento delle spese, tra cui la revisione dei contratti e l’ottimizzazione delle strategie di approvvigionamento.

Nonostante le recenti preoccupazioni, il programma CVE non ha subito alcuna interruzione: il 16 aprile 2025, la CISA ha esteso all’ultimo minuto il contratto con MITRE, garantendo la continuità dei servizi CVE per altri 11 mesi, proprio poche ore prima della scadenza prevista. Tuttavia, l’evoluzione degli eventi rimane imprevedibile. Il potenziale impatto negativo sulla condivisione dell’intelligence suscita allarme, configurando forse una nuova dimensione geopolitica, paragonabile a una forma di guerra fredda digitale.

Questo articolo fornisce una breve panoramica sul funzionamento del programma CVE e su come le capacità di rilevamento di Greenbone siano rimaste invariate durante l’interruzione del NIST NVD.

Funzionamento del programma CVE: una panoramica

La MITRE Corporation, organizzazione senza scopo di lucro, opera come pilastro strategico per la sicurezza interna statunitense abbracciando ricerca difensiva, protezione delle infrastrutture critiche e cybersecurity. Nella gestione del programma CVE, MITRE ricopre un ruolo centrale come Primary CNA (CVE Numbering Authority), coordinando l’infrastruttura chiave per l’assegnazione degli ID CVE, la pubblicazione dei record e i flussi di comunicazione tra tutti i CNA e gli Authorized Data Publishers (ADP). I dati CVE sono resi pubblici attraverso il sito web del MITRE CVE.org  e il repository cvelistV5 su GitHub, dove i record sono archiviati in formato JSON strutturato. Questo modello ha ottimizzato il reporting delle vulnerabilità, standardizzato i processi e assicurato una condivisione dei dati fluida nell’ecosistema della sicurezza informatica globale.

Quando in passato un CNA inviava una descrizione della vulnerabilità al MITRE, il NIST ha sempre aggiunto informazioni chiave quali:

  • CVSS (Common Vulnerability Scoring System): un punteggio di gravità (da 0 a 10) e una stringa vettoriale dettagliata che descrive il rischio associato alla vulnerabilità. Il CVSS valuta fattori come la complessità dell’attacco (Attack Complexity, AC), l’impatto su riservatezza (Confidentiality, C), integrità (Integrity, I) e disponibilità (Availability, A), oltre ad altri parametri.
  • CPE (Common Platform Enumeration): una stringa appositamente formattata che identifica in modo univoco i prodotti e le versioni interessate dalla vulnerabilità, includendo nome del prodotto, fornitore e dettagli architetturali.
  • CWE (Common Weakness Enumeration): classifica le cause profonde della vulnerabilità in base alla tipologia del difetto software.

ll CVSS consente alle organizzazioni di quantificare il rischio associato a una vulnerabilità attraverso un punteggio standardizzato (0-10), facilitando la prioritizzazione strategica degli interventi di bonifica. Poiché le segnalazioni CVE iniziali includono solo dichiarazioni non standardizzate sui prodotti coinvolti, l’integrazione dei CPE da parte del NIST consente alle piattaforme di sicurezza di utilizzare il matching CPE come metodo rapido, sebbene parzialmente inaffidabile, per identificare la presenza di vulnerabilità nell’infrastruttura di un’organizzazione.

Se desideri approfondire come funziona il procedimento di divulgazione delle vulnerabilità e il ruolo di CSAF 2.0 come alternativa decentralizzata al programma CVE del MITRE, leggi il nostro articolo: Cos’è il Common Security Advisory Framework 2.0 e come automatizza il vulnerability management. Di seguito procediamo ad esaminare le criticità del NIST NVD e identifichiamo gli elementi che garantiscono la capacità di Greenbone di rilevare le vulnerabilità nonostante il malfunzionamento del database federale.

Interruzione NVD del NIST: cos’è successo?

A partire dal 12 febbraio 2024, il NVD ha ridotto drasticamente l’arricchimento delle vulnerabilità CVE con metadati importanti come punteggi CVSS, identificatori CPE e classificazioni CWE. Il problema è emerso inizialmente grazie al vicepresidente della sicurezza di Anchore, che ne ha segnalato l’impatto operativo. A maggio 2024, circa il 93% delle CVE aggiunte dopo il 12 febbraio risultava privo di analisi contestuali. A settembre 2024, il NIST non ha rispettato la scadenza autoimposta per colmare il ritardo: il 72,4% delle CVE e il 46,7% delle KEV (Known Exploited Vulnerabilities) del CISA rimanevano non erano ancora state arricchite [3].

Il rallentamento del processo di arricchimento del National Vulnerability Database (NVD) ha avuto ripercussioni significative per la comunità della sicurezza informatica. Non solo perché i dati arricchiti sono fondamentali per i difensori nel definire con efficacia le priorità delle minacce, ma anche perché numerosi strumenti di scansione delle vulnerabilità si basano su questi metadati per rilevare e valutare le falle di sicurezza.

In qualità di difensore della cybersecurity, è lecito chiedersi se Greenbone sia stato colpito dall’interruzione del NIST NVD. La risposta è no. Continua a leggere per scoprire perché le capacità di rilevamento di Greenbone sono riuscite a far fronte all’interruzione del NIST NVD.

Il rilevamento di Greenbone risulta efficace nonostante l’interruzione NVD

Senza metadati CVE arricchiti, molte soluzioni di sicurezza risultano inefficaci a causa della dipendenza dalla corrispondenza CPE per identificare le vulnerabilità. Tuttavia, Greenbone è riuscito a far fronte all’interruzione del NIST NVD grazie a un approccio indipendente dal CPE: i test di vulnerabilità OpenVAS possono essere sviluppati direttamente dalle descrizioni CVE non arricchite, integrando anche il rilevamento di configurazioni errate e vulnerabilità senza CVE, come i benchmark CIS [4][5]. 

Per sviluppare i test di vulnerabilità (VT), Greenbone si avvale di un team dedicato di ingegneri software specializzati nell’analisi degli aspetti tecnici alla base delle vulnerabilità. Il sistema include uno scanner CVE in grado di eseguire una corrispondenza CPE tradizionale, ma si distingue dalle soluzioni dipendenti esclusivamente dai dati CPE del NIST NVD grazie a tecniche di rilevamento avanzate che superano i limiti del matching di base. Questa architettura ibrida – tra automazione standardizzata e analisi contestuale – garantisce capacità di rilevamento solide anche durante interruzioni critiche come quella recente del NIST NVD.

Per garantire un rilevamento delle vulnerabilità resiliente e all’avanguardia, lo scanner OpenVAS di Greenbone interagisce attivamente con i servizi di rete esposti, costruendo una mappa dettagliata della superficie di attacco di una rete target. Questo comprende l’identificazione dei servizi accessibili tramite connessioni di rete, l’analisi dei prodotti in esecuzione e l’esecuzione di test specifici (VT) per ogni vulnerabilità CVE o non-CVE, verificandone attivamente la presenza. L’Enterprise Vulnerability Feed di Greenbone include oltre 180.000 VT aggiornati quotidianamente, garantendo il rilevamento tempestivo delle ultime vulnerabilità segnalate e un’individuazione rapida delle minacce emergenti.

Oltre alle scansioni attive, Greenbone integra scansioni autenticate agentless che raccolgono dati dettagliati dagli endpoint, analizzando i pacchetti software installati e confrontandoli con i CVE noti. Questo approccio garantisce un rilevamento preciso delle vulnerabilità, bypassando la dipendenza dai dati CPE arricchiti del NVD.

Punti di forza:

  • Indipendenza dai dati CVE arricchiti: Greenbone garantisce il rilevamento continuo senza dipendere dai metadati arricchiti del NIST NVD, mantenendo prestazioni stabili anche durante interruzioni del database federale. Una descrizione di base di una vulnerabilità consente agli ingegneri di Greenbone di sviluppare un modulo di rilevamento.
  • Rilevamento avanzato oltre il CPE: sebbene Greenbone includa uno scanner CVE con corrispondenza CPE, le sue capacità si estendono ben oltre questo approccio tradizionale, integrando metodi attivi di interazione con i target per un rilevamento più accurato.
  • Mappatura della superficie di attacco: lo scanner OpenVAS di Greenbone interagisce attivamente con i servizi esposti per mappare la superficie di attacco della rete, identificando tutti i servizi raggiungibili. Le scansioni autenticate agentless raccolgono dati direttamente dagli endpoint per analizzare i pacchetti software installati, confrontandoli con i CVE noti senza dipendere dai dati CPE arricchiti.
  • Resilienza alle interruzioni dell’arricchimento NVD: il rilevamento di Greenbone risulta efficace anche senza dati NVD arricchiti, perché si serve delle descrizioni CVE dei CNA per sviluppare controlli attivi precisi e valutazioni basate sulle versioni software.

L’approccio di Greenbone è pratico, efficace e resistente

Greenbone rappresenta il punto di riferimento in termini di praticità, efficacia e resilienza nel campo della gestione delle vulnerabilità. Le sue soluzioni sono progettate per fornire una protezione proattiva e affidabile contro le minacce informatiche, adattandosi a una vasta gamma di ambienti IT. Utilizzando la mappatura attiva della rete e le scansioni autenticate, le soluzioni Greenbone interagiscono direttamente con l’infrastruttura di destinazione.

Questi standard elevati permettono alle aziende di identificare le vulnerabilità in modo preciso e tempestivo, anche in ambienti complessi e distribuiti. Anche in assenza dell’arricchimento del National Vulnerability Database (NVD), i metodi di rilevamento delle vulnerabilità di Greenbone rimangono efficaci e affidabili. Gli ingegneri di Greenbone possono sviluppare controlli attivi accurati e valutazioni delle vulnerabilità basate sulla versione del prodotto, utilizzando le informazioni disponibili nei rapporti iniziali dei CVE.

Grazie a un approccio intrinsecamente resiliente nel rilevamento delle vulnerabilità, Greenbone assicura una gestione affidabile delle minacce, emergendo come punto di riferimento nel panorama della cybersecurity.

Alternative a NVD / NIST / MITRE

La problematica del MITRE rappresenta un campanello d’allarme per la sovranità digitale europea, ma l’UE ha reagito con tempestività: l’EuVD di ENISA, l’Agenzia dell’Unione per la cybersecurity, è ora operativa. Ne parleremo nel nostro prossimo articolo.

Contatto Prova Ora Acquista Torna alla Panoramica

/da
Joseph Lee

Quali sono gli stakeholder e i ruoli del CSAF 2.0

Il Common Security Advisory Framework (CSAF) è un sistema progettato per fornire avvisi di sicurezza leggibili dalle macchine attraverso un processo standardizzato che facilita la condivisione automatizzata delle informazioni sulla sicurezza informatica. Greenbone sta attivamente lavorando per integrare tecnologie basate sullo standard CSAF 2.0 con l’obiettivo di automatizzare gli avvisi di sicurezza informatica. Per un’introduzione a CSAF 2.0 e una panoramica dei benefici che apporta alla gestione delle vulnerabilità, ti invitiamo a consultare il nostro .

Nel 2024, l’interruzione del NIST National Vulnerabilities Database (NVD)  ha di dati critici verso i consumatori a valle, sottolineando la necessità di soluzioni più resilienti e distribuite. Il modello CSAF 2.0 decentralizzato si dimostra particolarmente rilevante in questo contesto, offrendo un quadro di condivisione delle informazioni che elimina la dipendenza da un singolo punto di errore. Grazie alla sua capacità di aggregare dati da una varietà di fonti affidabili, CSAF 2.0 garantisce una continuità operativa e una maggiore affidabilità nella distribuzione degli avvisi di sicurezza.

Indice

1. Di cosa parleremo in questo articolo
2. Chi sono gli stakeholder di CSAF?
2.1. I ruoli nel protocollo CSAF 2.0
2.1.1. Soggetti emittenti di CSAF 2.0
2.1.1.1. Il ruolo di editore di CSAF
2.1.1.2. Il ruolo di fornitore di CSAF
2.1.1.3. Il ruolo di trusted-provider di CSAF
2.1.2. Aggregatori di dati CSAF 2.0
2.1.2.1. Il ruolo di lister CSAF
2.1.2.2. Il ruolo di aggregatore CSAF
3. Conclusione

1. Di cosa parleremo in questo articolo

Questo articolo vuole approfondire quali sono gli stakeholder e i ruoli definiti nella specifica CSAF 2.0, che governano i meccanismi di creazione, diffusione e consumo degli avvisi di sicurezza all’interno dell’ecosistema CSAF 2.0. Comprendere chi sono gli stakeholder di CSAF e come i ruoli standardizzati definiti dal framework influenzano l’intero ciclo di vita delle informazioni sulle vulnerabilità è essenziale per i professionisti della sicurezza. Questo approfondimento aiuterà a comprendere meglio come funziona CSAF, come può essere utile per la propria organizzazione e come implementarlo efficacemente nel contesto della gestione delle vulnerabilità.

2. Chi sono gli stakeholder di CSAF?

A livello generale, il processo CSAF coinvolge due principali gruppi di stakeholder: i produttori a monte, che creano e distribuiscono avvisi di sicurezza informatica nel formato CSAF 2.0, e i consumatori a valle (utenti finali), che utilizzano questi avvisi per implementare le informazioni di sicurezza in essi contenute.

I produttori a monte includono fornitori di software come Cisco, e Oracle responsabili della sicurezza dei loro prodotti digitali e della divulgazione pubblica delle vulnerabilità identificate. Tra gli stakeholder a monte si annoverano anche ricercatori indipendenti e agenzie pubbliche come la Cybersecurity and Infrastructure Security Agency (CISA) negli Stati Uniti e l’Ufficio federale tedesco per la sicurezza delle informazioni (BSI), che fungono da fonti autorevoli per l’intelligence sulla sicurezza informatica.

I consumatori a valle includono sia società private che gestiscono direttamente la propria sicurezza informatica, sia , ovvero fornitori esterni che offrono servizi di monitoraggio e gestione della sicurezza in outsourcing. A valle, i team di sicurezza IT utilizzano le informazioni contenute nei documenti CSAF 2.0 per individuare vulnerabilità nell’infrastruttura e pianificare interventi di mitigazione. Allo stesso tempo, i dirigenti aziendali sfruttano questi dati per comprendere come i rischi IT potrebbero sulle operazioni aziendali.

Diagramma che illustra i portatori di interesse del CSAF 2.0: i produttori a monte, come fornitori di software e enti pubblici, forniscono avvisi di sicurezza nel formato CSAF 2.0, utilizzati dai consumatori a valle, tra cui organizzazioni private, CERT governativi e provider di sicurezza.

Flusso CSAF 2.0 dai produttori a monte ai consumatori a valle per avvisi di sicurezza di base

Lo standard CSAF 2.0 definisce ruoli specifici per i produttori a monte che delineano la loro partecipazione alla creazione e alla diffusione di documenti informativi. Esaminiamo più in dettaglio questi ruoli ufficialmente definiti.

2.1. I ruoli nel protocollo CSAF 2.0

I ruoli CSAF 2.0 sono definiti nella sezione 7.2. Si dividono in due gruppi distinti: i soggetti emittenti (“emittenti”) e gli aggregatori di dati (“aggregatori”). Gli emittenti sono direttamente coinvolti nella creazione di documenti informativi. Gli aggregatori raccolgono i documenti CSAF e li distribuiscono agli utenti finali, facilitando l’automazione per i consumatori. Sebbene una singola organizzazione possa ricoprire sia il ruolo di Emittente che quello di Aggregatore, è importante che queste due funzioni operino come entità distinte.  Inoltre, le organizzazioni che agiscono come produttori a monte devono anche garantire la propria sicurezza informatica. Per questo motivo, possono svolgere il ruolo di consumatori a valle, utilizzando i documenti CSAF 2.0 per sostenere le proprie attività di gestione delle vulnerabilità.

Diagramma dei ruoli a monte nel protocollo CSAF 2.0: i soggetti emittenti (Producer, Provider, Trusted Provider) creano documenti, mentre gli aggregatori di dati (Lister, Aggregator) li raccolgono e distribuiscono ai consumatori a valle.

Diagramma che illustra la relazione tra i soggetti emittenti e gli aggregatori di dati CSAF 2.0.

Di seguito esaminiamo le responsabilità specifiche dei soggetti emittenti e degli aggregatori di dati CSAF 2.0.

2.1.1. Soggetti emittenti di CSAF 2.0

I soggetti emittenti sono responsabili della creazione degli avvisi di sicurezza informatica CSAF 2.0. Tuttavia, non sono responsabili per la trasmissione dei documenti agli utenti finali. Se i soggetti emittenti non desiderano che i loro avvisi vengano elencati o replicati dagli aggregatori di dati lo devono segnalare. Inoltre, i soggetti emittenti di CSAF 2.0 possono anche svolgere il ruolo di aggregatori di dati.

Di seguito le spiegazioni di ciascun ruolo secondario all’interno del gruppo dei soggetti emittenti:

2.1.1.1. Il ruolo di editore di CSAF

Gli editori sono generalmente organizzazioni che scoprono e comunicano avvisi esclusivamente per i propri prodotti digitali. Per adempiere al loro ruolo, gli editori devono rispettare i requisiti da 1 a 4 della sezione 7.1 della specifica CSAF 2.0. Questo implica la creazione di file strutturati con sintassi e contenuti validi, conformi alle convenzioni sui nomi dei file CSAF 2.0 descritte nella sezione 5.1, e la garanzia che i file siano accessibili solo tramite connessioni TLS crittografate. Inoltre, gli editori devono rendere pubblici tutti gli avvisi classificati come TLP:WHITE.

Gli editori devono inoltre mettere a disposizione del pubblico un documento provider-metadata.json contenente informazioni di base sull’organizzazione, sul suo stato di ruolo CSAF 2.0 e sui collegamenti a una chiave pubblica OpenPGP utilizzata per firmare digitalmente il documento provider-metadata.json e verificarne l’integrità. Queste informazioni vengono utilizzate da applicazioni software che, a valle, visualizzano gli avvisi dell’editore agli utenti finali.

2.1.1.2. Il ruolo di fornitore di CSAF

I fornitori rendono disponibili i documenti CSAF 2.0 alla comunità più ampia. Oltre a soddisfare gli stessi requisiti di un editore, un fornitore deve fornire il proprio file provider-metadata.json seguendo un metodo standardizzato (soddisfacendo almeno uno dei requisiti da 8 a 10 della sezione 7.1), utilizzare una distribuzione standardizzata per i suoi avvisi e implementare controlli tecnici per limitare l’accesso a qualsiasi documento informativo classificato come TLP:AMBER or TLP:RED.

I fornitori devono anche scegliere un metodo di distribuzione basato su directory o su ROLIE. In breve, la distribuzione basata su directory rende disponibili i documenti informativi all’interno di una normale struttura di percorsi di directory, mentre ROLIE (Resource-Oriented Lightweight Information Exchange) [RFC-8322] è un protocollo API RESTful progettato specificamente per automatizzare la sicurezza, la pubblicazione, la scoperta e la condivisione delle informazioni.

Se un fornitore utilizza la distribuzione basata su ROLIE, deve anche soddisfare i requisiti da 15 a 17 dalla sezione 7.1. In alternativa, se un fornitore utilizza la distribuzione basata su directory, deve rispettare i requisiti da 11 a 14 della sezione 7.1.

2.1.1.3. Il ruolo di trusted-provider di CSAF

I Trusted Provider sono una categoria speciale di provider CSAF che hanno raggiunto un elevato livello di fiducia e affidabilità. Devono rispettare rigorosi standard di sicurezza e qualità per garantire l’integrità dei documenti CSAF che emettono.

Oltre a soddisfare tutti i requisiti di un fornitore CSAF, i Trusted Provider devono anche rispettare i requisiti da 18 a 20 della sezione 7.1 della specifica CSAF 2.0. Questi requisiti comprendono la fornitura di un hash crittografico sicuro e di un file di firma OpenPGP per ciascun documento CSAF emesso, nonché la garanzia che la parte pubblica della chiave di firma OpenPGP sia resa pubblicamente disponibile.

2.1.2. Aggregatori di dati CSAF 2.0

Gli aggregatori di dati si occupano della raccolta e della ridistribuzione dei documenti CSAF. Funzionano come directory per gli emittenti CSAF 2.0 e i loro documenti informativi, fungendo da intermediari tra gli emittenti e gli utenti finali. Una singola entità può svolgere sia il ruolo di Lister che di aggregatore CSAF. Gli aggregatori di dati hanno la possibilità di scegliere quali avvisi degli editori upstream elencare, raccogliere e ridistribuire, in base alle esigenze dei loro clienti.

Di seguito la spiegazione di ciascun ruolo secondario all’interno del gruppo degli aggregatori di dati:

2.1.2.1. Il ruolo di lister CSAF

I lister raccolgono i documenti CSAF da più editori CSAF e li elencano in una posizione centralizzata per facilitarne il recupero. L’obiettivo di un lister è fungere da directory per gli avvisi CSAF 2.0, consolidando gli URL attraverso cui è possibile accedere ai documenti CSAF. Si presume che nessun lister fornisca un set completo di tutti i documenti CSAF.

I lister devono pubblicare un file aggregator.json valido che elenchi almeno due entità CSAF Provider separate. Sebbene un lister possa anche agire come parte emittente, non può elencare mirror che puntano a un dominio sotto il proprio controllo.

2.1.2.2. Il ruolo di aggregatore CSAF

Il ruolo di CSAF Aggregator rappresenta il punto finale di raccolta tra i documenti informativi CSAF 2.0 pubblicati e l’utente finale.  Gli aggregatori offrono una posizione in cui i documenti CSAF possono essere recuperati da strumenti automatizzati. Sebbene gli aggregatori agiscano come una fonte consolidata di avvisi di sicurezza informatica, simile al NIST NVD o al CVE.org di The MITRE Corporation, CSAF 2.0 adotta un modello decentralizzato, in contrasto con un approccio centralizzato. Gli aggregatori non sono obbligati a fornire un elenco completo di documenti CSAF di tutti gli editori. Inoltre, gli editori possono scegliere di offrire l’accesso gratuito al loro feed di consulenza CSAF o di operare come servizio a pagamento.

Analogamente ai lister, gli aggregatori devono rendere un file aggregator.json disponibile pubblicamente. Inoltre, i documenti CSAF di ciascun emittente con mirroring devono essere organizzati in una cartella dedicata separata, contenente anche il file provider-metadata.json dell’emittente. Per adempiere al loro ruolo, gli aggregatori devono rispettare i requisiti da 1 a 6 e da 21 a 23 della sezione 7.1 della specifica CSAF 2.0.

Gli aggregatori CSAF sono responsabili di verificare che ogni documento CSAF replicato abbia una firma valida (requisito 19) e un hash crittografico sicuro (requisito 18). Se il soggetto emittente non fornisce questi file, l’aggregatore deve generarli.

3. Conclusione

Comprendere gli stakeholder e i ruoli di CSAF 2.0 è fondamentale per implementare correttamente la specifica e sfruttare i vantaggi della raccolta e del consumo automatizzati di informazioni critiche sulla sicurezza informatica. CSAF 2.0 identifica due principali gruppi di stakeholder: i produttori a monte, responsabili della creazione di avvisi di sicurezza, e i consumatori a valle, che utilizzano queste informazioni per migliorare la sicurezza. I ruoli definiti includono i soggetti emittenti (editori, fornitori e fornitori di fiducia) che generano e distribuiscono avvisi, e gli aggregatori di dati (lister e aggregatori) che raccolgono e diffondono questi avvisi agli utenti finali.

I membri di ogni ruolo devono rispettare specifici controlli di sicurezza per garantire la trasmissione sicura dei documenti CSAF 2.0.  Inoltre, il Traffic Light Protocol (TLP) regola le modalità di condivisione dei documenti e definisce i controlli di accesso necessari per rispettare le autorizzazioni di distribuzione.

Contatto Prova Ora Acquista Torna alla Panoramica

/da
Joseph Lee

Cos’è il Common Security Advisory Framework 2.0 e come automatizza il vulnerability management

Chi lavora nel settore della sicurezza informatica non deve necessariamente sapere cos’è il Common Security Advisory Framework (CSAF). Tuttavia, capire come funziona una piattaforma di vulnerability management può aiutare a capire come si stanno evolvendo le soluzioni di nuova generazione e quali vantaggi presenta la gestione delle vulnerabilità automatizzata. In questo articolo scopriremo cos’è il CSAF 2.0 e come questo standard può migliorare la gestione delle vulnerabilità all’interno delle aziende. 

Greenbone AG è partner ufficiale dell’Ufficio Federale Tedesco per la Sicurezza Informatica (BSI), con cui collabora nell’integrazione di tecnologie basate sullo standard CSAF 2.0, progettate per fornire raccomandazioni di sicurezza informatica automatizzate.

Cos’è il CSAF?

Il Common Security Advisory Framework (CSAF) 2.0 è uno standard aperto che rende gli avvisi di vulnerabilità leggibili dalle macchine. Grazie a questo formato, tutti gli attori della cybersecurity (dai fornitori di software e hardware fino ai governi e ai ricercatori indipendenti) sono in grado di condividere e raccogliere informazioni in modo più efficiente. A differenza dei metodi tradizionali, il CSAF consente agli utenti di centralizzare gli avvisi provenienti da un gruppo decentralizzato di provider e di automatizzare la valutazione del rischio.

Grazie al suo formato standardizzato e leggibile dalle macchine, il Common Security Advisory Framework segna un importante progresso verso la gestione automatizzata e di nuova generazione delle vulnerabilità. Questo standard aiuta i reparti IT aziendali a gestire con maggiore efficienza il , alleggerendo il loro carico di lavoro e migliorando la capacità di prendere decisioni basate sul rischio.

Il CSAF 2.0 rappresenta l’evoluzione del Common Vulnerability Reporting Framework (CVRF) e ha funzionalità ampliate che garantiscono una maggiore flessibilità.

Tra i principali punti di forza di CSAF 2.0 spiccano:

  • La definizione di uno standard internazionale aperto per documenti leggibili dalle macchine, che utilizzano il linguaggio di markup JSON per riferirsi alle vulnerabilità.
  • L’introduzione di un modello decentralizzato per l’aggregazione delle informazioni sulle vulnerabilità.
  • La progettazione mirata a supportare la gestione automatizzata delle vulnerabilità di nuova generazione.

Il processo tradizionale di vulnerability management

Per le organizzazioni di grandi dimensioni, gestire le vulnerabilità secondo i metodi tradizionali è un incubo. Il numero di CVE rilasciate ad ogni ciclo di patch continua a crescere a un ritmo esponenziale . I reparti di sicurezza informatica devono raccogliere manualmente le informazioni sulle vulnerabilità tramite ricerche online. Questo metodo richiede un notevole impegno manuale per raccogliere, analizzare e organizzare i dati provenienti da una moltitudine di fonti e documenti spesso strutturati in formati non uniformi.

Queste fonti di solito includono:

  • Database di tracciamento delle vulnerabilità, come il NIST NVD
  • Istruzioni di sicurezza del fornitore del prodotto
  • Consultazioni nazionali e internazionali del CERT
  • Valutazioni da parte dell’autorità di numerazione CVE (CNA)
  • Ricerca indipendente sulla sicurezza
  • Piattaforme per le informazioni sulla sicurezza
  • Database di exploit di codice

Una valutazione del rischio accurata e affidabile può essere compromessa in diversi modi nel corso di questo processo. Le raccomandazioni, persino quelle fornite dai produttori, risultano spesso incomplete e presentate in formati eterogenei e non standardizzati. Questa mancanza di uniformità ostacola un processo decisionale basato sui dati, aumentando significativamente il rischio di errori.

Analizziamo brevemente la pipeline delle informazioni sulle vulnerabilità, considerando sia la prospettiva dei produttori che quella dei consumatori:

Il processo di divulgazione delle vulnerabilità

I dataset Common Vulnerability and Exposure (CVE) pubblicati nel National Vulnerability Database (NVD) del NIST (National Institute of Standards and Technology), costituiscono l’archivio globale più centralizzato e autorevole per le informazioni sulle vulnerabilità. Di seguito è riportata una panoramica del funzionamento del processo di divulgazione delle vulnerabilità:

  1. I fornitori di prodotti rilevano vulnerabilità attraverso test di sicurezza interni o segnalazioni da parte di ricercatori indipendenti. Questo avvia una politica interna di divulgazione delle vulnerabilità. In alcuni casi, i ricercatori indipendenti collaborano direttamente con una CVE Numbering Authority (CNA) per pubblicare la vulnerabilità, bypassando il coinvolgimento iniziale del fornitore del prodotto.
  2. Aggregatori di vulnerabilità come il NIST NVD e i assegnano un ID di tracciamento univoco (ad esempio, un ID CVE) alla vulnerabilità segnalata e la aggiungono a un database centrale che consente agli utenti dei prodotti e a piattaforme di gestione delle vulnerabilità, , di monitorare i progressi e le eventuali correzioni.
  3. Diversi stakeholder, tra cui il produttore, il NIST NVD e ricercatori indipendenti, pubblicano avvisi di sicurezza. Tali avvisi possono includere informazioni relative a patch, date di pubblicazione di patch ufficiali, elenco di prodotti interessati, , livelli di gravità e riferimenti tecnici come Common Platform Enumeration (CPE) e Common Weakness Enumeration (CWE).
  4. Fornitori di informazioni sulle minacce informatiche, come Known Exploited Vulnerabilities (KEV) della CISA ed Exploit Prediction Scoring System (EPSS) di First.org, aggiungono ulteriori dettagli contestuali.

Il processo di gestione delle vulnerabilità

Gli utenti dei prodotti devono leggere le informazioni sulle vulnerabilità e applicarle per mitigare il rischio di sfruttamento. Ecco una panoramica del processo di gestione delle vulnerabilità nelle organizzazioni:

  1. Gli utenti dei prodotti devono cercare manualmente nei database CVE e monitorare gli avvisi di sicurezza relativi ai loro asset software e hardware. In alternativa, possono utilizzare piattaforme di gestione delle vulnerabilità, , che aggregano automaticamente gli avvisi di minacce provenienti da fonti varie.
  2. Gli utenti devono confrontare le informazioni sulle vulnerabilità con il proprio inventario IT. Questo processo consiste nell’aggiornamento di un inventario esistente e può essere eseguito manualmente o utilizzando un che automatizza la creazione dell’inventario e l’esecuzione dei test di vulnerabilità.
  3. I team di sicurezza informatica classificano le vulnerabilità scoperte in base al rischio contestuale per i sistemi IT critici, i processi aziendali e, in alcuni casi, la sicurezza pubblica.
  4. I task di mitigazione vengono assegnati in base alla valutazione finale del rischio e alle risorse disponibili.

Cosa non funziona nella gestione delle vulnerabilità tradizionale?

Le procedure tradizionali per la gestione delle vulnerabilità, che spesso si basano su processi manuali, si rivelano nella pratica complesse e poco efficienti. Oltre alle difficoltà operative legate all’implementazione delle patch software, la mancanza di informazioni accessibili e affidabili rende più difficile individuare rapidamente le vulnerabilità e intervenire con soluzioni mirate. Anche l’utilizzo esclusivo del CVSS come metodo di valutazione del rischio presenta dei limiti: è stato criticato [2], perché non offre un contesto sufficientemente ricco per guidare . Anche se piattaforme possono alleviare parte del lavoro dei team di sicurezza, il processo complessivo resta ancora appesantito dalla necessità di raccogliere manualmente spesso frammentarie e poco strutturate.

Con l’aumento costante del numero di vulnerabilità, l’aggregazione ad hoc delle informazioni di sicurezza rischia di essere troppo lenta e di introdurre più errori umani. Questo può prolungare il tempo di esposizione alle vulnerabilità e complicare la prioritizzazione basata sul rischio.

La mancanza di standardizzazione porta a un’intelligence frammentata

L’attuale processo di divulgazione delle vulnerabilità manca di un metodo formale per distinguere tra le informazioni affidabili messe a disposizione dai fornitori e quelle fornite da ricercatori di sicurezza indipendenti come i partner CNA. In effetti, lo stesso sito web ufficiale del CVE pubblicizza che per aderire al CNA sono necessari requisiti minimi. Questo fa sì che un gran numero di CVE venga rilasciato in assenza di un contesto dettagliato, costringendo a ricerche più dettagliate a valle.

Le informazioni fornite sono lasciate alla discrezione della CNA, e non esiste un metodo standard per valutarne l’affidabilità. Un esempio lampante di questo problema si riscontra nella specificazione dei prodotti interessati, spesso inseriti in avvisi ad hoc con descrittori variabili e non standardizzati che richiedono un’interpretazione manuale. Ad esempio:

  • Versione 8.0.0 – 8.0.1
  • Versione 8.1.5 e successive
  • Versione <= 8.1.5
  • Versioni precedenti alla 8.1.5
  • Tutte le versioni < V8.1.5
  • 0, V8.1, V8.1.1, V8.1.2, V8.1.3, V8.1.4, V8.1.5

Scalabilità

Poiché fornitori, auditor (CNA) e aggregatori adottano metodi e formati di distribuzione eterogenei per le loro notifiche, la gestione efficiente delle vulnerabilità diventa una sfida operativa complessa e difficilmente scalabile. Questo problema è ulteriormente aggravato dall’aumento continuo delle vulnerabilità segnalate, che mette sotto pressione i processi manuali, sovraccarica i team di sicurezza e incrementa il rischio di errori o ritardi nelle attività di mitigazione.

Difficile contesto della valutazione di rischio

La sezione 3 del NIST SP 800-40r4 “Guide to Enterprise Patch Management Planning” suggerisce l’adozione di metriche di vulnerabilità orientate al contesto aziendale. Tuttavia, poiché il rischio associato a una vulnerabilità dipende in ultima analisi da fattori specifici come i sistemi coinvolti, l’impatto potenziale e la facilità di sfruttamento, l’attuale panorama frammentato delle informazioni di sicurezza rappresenta un serio ostacolo per una gestione delle vulnerabilità basata sul rischio.

In che modo CSAF 2.0 risolve questi problemi?

I documenti CSAF sono avvisi essenziali sulle minacce informatiche progettati per ottimizzare la catena di approvvigionamento delle informazioni sulla vulnerabilità. Invece di aggregare manualmente dati sulle vulnerabilità in modo frammentario, gli utenti del prodotto possono sfruttare l’aggregazione automatica degli avvisi CSAF da fonti affidabili. Questo approccio consente di integrarli in un sistema di gestione che combina funzionalità fondamentali, come la corrispondenza degli asset e la valutazione del rischio. In questo modo, l’automazione dei contenuti di sicurezza con CSAF affronta le sfide della gestione tradizionale delle vulnerabilità fornendo una security intelligence più affidabile ed efficiente e creando il potenziale per una gestione delle vulnerabilità di nuova generazione.

Ecco alcuni modi specifici in cui CSAF 2.0 risolve i problemi della gestione tradizionale delle vulnerabilità:

Informazioni sulla sicurezza più affidabili

CSAF 2.0 diminuisce la frammentazione delle informazioni di sicurezza introducendo una standardizzazione avanzata nei processi di divulgazione delle vulnerabilità. Grazie a campi strutturati per identificare le versioni dei prodotti interessati, il framework consente l’impiego di dati standardizzati come il Version Range Specifier (vers), il Common Platform Enumeration (CPE), il Package URL specification e il CycloneDX SBOM. Oltre a questi formati tecnici, CSAF supporta anche l’uso di identificatori più generali, come il nome del prodotto, il numero di serie, il numero di modello, lo SKU o persino l’hash del file.

Oltre a introdurre una standardizzazione per le versioni dei prodotti, offre anche un’importante innovazione con il Vulnerability Exploitability eXchange (VEX). Questo strumento permette ai produttori, ai fornitori CSAF di fiducia e persino ai ricercatori di sicurezza indipendenti di relative ai prodotti interessati.

Le dichiarazioni di stato VEX esplicite sono:

  • Non interessato: non è necessaria alcuna azione correttiva in relazione a una vulnerabilità.
  • Interessato: si consigliano misure per correggere o eliminare una vulnerabilità.
  • Risolto: significa che queste versioni del prodotto contengono una correzione per una vulnerabilità di sicurezza.
  • In corso di verifica: non è ancora noto se queste versioni del prodotto siano affette da una vulnerabilità di sicurezza. Un aggiornamento sarà reso disponibile in una versione successiva.

    Uso più efficace delle risorse

CSAF introduce numerose opportunità per ottimizzare sia la parte iniziale che quella finale del tradizionale processo di gestione delle vulnerabilità. La documentazione ufficiale di OASIS CSAF 2.0 descrive diversi obiettivi di conformità, pensati per aiutare i responsabili IT a sfruttare l’automazione e rendere le operazioni di sicurezza più rapide ed efficienti.

Ecco alcuni degli obiettivi di conformità chiave inclusi in CSAF 2.0, progettati per superare i limiti del processo tradizionale e consentire un utilizzo più efficace delle risorse:

  • Sistema di gestione degli avvisi: questo sistema software è progettato per elaborare dati grezzi e trasformarli in documenti di avviso conformi a CSAF 2.0. La sua implementazione consente ai team che producono avvisi CSAF di monitorare la qualità dei dati in entrata, valutarli accuratamente, convertirli nel formato standardizzato e pubblicarli come avvisi di sicurezza validi. Questo approccio non solo migliora l’efficienza della pipeline informativa, ma garantisce anche che gli avvisi rilasciati siano precisi e affidabili, offrendo un supporto più solido agli utenti finali.
  • Sistema di gestione CSAF: questo programma è progettato per gestire i documenti CSAF e visualizzarne i dettagli in conformità con i requisiti del visualizzatore CSAF. A livello di base, consente sia ai produttori che ai consumatori di avvisi di sicurezza di visualizzare il contenuto dei documenti in un formato facilmente comprensibile e leggibile dall’uomo.
  • CSAF asset matching system / SBOM matching system: un sistema avanzato che si integra con un database di asset IT, inclusa la Software Bill of Materials (SBOM), per confrontare gli asset registrati con tutti gli avvisi CSAF disponibili. Questo strumento offre una panoramica chiara e dettagliata della struttura IT di un’organizzazione, consentendo di individuare rapidamente prodotti vulnerabili. Inoltre, fornisce dati strutturati per facilitare valutazioni automatizzate del rischio e supportare strategie di bonifica efficienti e mirate.
  • Sistema tecnico: un ambiente integrato dedicato all’analisi e allo sviluppo del software, in cui possono operare diversi strumenti specifici. Questo sistema comprende componenti come il sistema di compilazione, il sistema di controllo delle versioni, il sistema di gestione dei risultati, il sistema di tracciamento dei difetti e il sistema di esecuzione dei test.

Informazioni decentralizzate sulla sicurezza informatica

Il del processo di arricchimento del CVE nel National Vulnerability Database (NVD) del NIST evidenzia i rischi associati all’affidarsi esclusivamente a una singola fonte per le informazioni sulle vulnerabilità. CSAF, al contrario, adotta un approccio decentralizzato, permettendo agli utenti a valle di accedere e integrare informazioni provenienti da una varietà di fonti. Questo modello decentralizzato non solo migliora la resilienza complessiva del sistema, riducendo il rischio derivante dal fallimento di un unico fornitore, ma distribuisce anche in modo più equo l’onere dell’arricchimento delle vulnerabilità tra un numero maggiore di parti interessate.

I principali fornitori di prodotti IT aziendali come e Cisco hanno già implementato feed CSAF e VEX. Allo stesso tempo, diverse agenzie governative di cybersecurity e programmi CERT nazionali, tra cui l’Ufficio Federale tedesco per la Sicurezza Informatica (BSI) e l’Agenzia per la Sicurezza delle Infrastrutture e la Cybersecurity degli Stati Uniti (CISA) hanno sviluppato funzionalità per supportare lo scambio di informazioni basato su CSAF 2.0.

Il modello decentralizzato offre un ulteriore vantaggio: permette a più stakeholder di contribuire alla valutazione di una vulnerabilità specifica. Questo significa che, laddove un avviso o un’analisi risultino incompleti, altre fonti possono colmare tali lacune, fornendo un quadro più completo e approfondito.

Miglioramento della valutazione dei rischi e della definizione delle priorità delle vulnerabilità

Nel complesso, CSAF 2.0 migliora la gestione delle vulnerabilità, offrendo valutazioni più precise e interventi più rapidi. I fornitori possono rilasciare avvisi VEX affidabili, fornendo informazioni accurate per azioni correttive. L’introduzione dell’oggetto aggregate severity (aggregate_severity) semplifica l’analisi del rischio e la definizione delle priorità, riducendo il tempo di esposizione alle vulnerabilità critiche e aumentando la resilienza IT.

Conclusione

I metodi tradizionali di gestione delle vulnerabilità presentano gravi limitazioni dovute alla mancanza di standardizzazione, che si traducono in problemi di affidabilità, scalabilità e difficoltà nell’analisi del contesto di rischio e della probabilità di sfruttamento.

Il Common Security Advisory Framework (CSAF) 2.0 rappresenta un’evoluzione significativa in questo ambito, mirata a trasformare il processo di gestione delle vulnerabilità. Questo standard introduce un formato leggibile dalle macchine per lo scambio di informazioni sulle vulnerabilità, garantendo una raccolta più automatizzata e affidabile. Inoltre, decentralizzando le fonti di queste informazioni, CSAF 2.0 offre alle organizzazioni l’opportunità di accedere a dati di sicurezza più consistenti e verificabili, facilitando una gestione delle vulnerabilità più precisa, efficiente e scalabile.

Greenbone AG è partner ufficiale dell’Ufficio Federale Tedesco per la Sicurezza Informatica (BSI), con cui collabora nell’integrazione di tecnologie basate sullo standard CSAF 2.0, progettate per fornire raccomandazioni di sicurezza informatica automatizzate.

Contatto Prova Ora Acquista Torna alla Panoramica

/da