Tag Archivio per: Sicurezza IT

Greenbone AG

Intuitivo e trasparente: una panoramica completa e aggiornata della sicurezza della tua infrastruttura IT, per tutti i livelli decisionali

OPENVAS REPORT nostro ultimo prodotto, è in grado di aggregare i dati provenienti da un numero pressoché illimitato di Greenbone Enterprise Appliance, presentandoli in modo chiaro su una dashboard ben strutturata. L’interfaccia user-friendly e completa semplifica notevolmente la protezione e la messa in sicurezza anche di reti di grandi dimensioni.

Dal 2008, Greenbone AG sviluppa tecnologie open source leader per la gestione automatizzata delle vulnerabilità. Oltre 100.000 organizzazioni in tutto il mondo si affidano alla Community di Greenbone e alle edizioni Enterprise per rafforzare la loro resilienza informatica.

“OPENVAS REPORT è sinonimo di innovazione da parte del leader del mercato open source.”

“Con il nostro nuovo prodotto riduciamo in modo decisivo la lacuna fra le attuali conoscenze di sicurezza e la capacità di agire in modo più rapido, chiaro e flessibile che mai”, dichiara il Dott. Jan-Oliver Wagner, CEO di Greenbone AG.

Riconoscere le situazioni di rischio in modo più rapido ed efficace

Per proteggere le proprie infrastrutture digitali è fondamentale essere sempre aggiornati sugli eventi relativi alla sicurezza e mantenere i tempi di risposta agli eventi critici il più brevi possibili.

OPENVAS REPORT fornisce una panoramica completa e aggiornata della situazione della sicurezza dell’infrastruttura IT, per tutti i livelli decisionali.

Grazie alle appliance aziendali Greenbone collegate, OPENVAS REPORT rileva automaticamente computer e software in azienda. Gli utenti possono contrassegnarli con parole chiave, raggrupparli e ordinarli a proprio piacimento, così da mantenere una visione d’insieme anche in reti molto grandi.

Dashboard moderna e intuitiva

La dashboard di OPENVAS REPORT è uno strumento moderno, intuitivo e altamente flessibile. Consente, ad esempio, di filtrare e ordinare i dati in base alla gravità generale o al rischio specifico delle vulnerabilità. Le aziende possono così creare autonomamente visualizzazioni personalizzate che mostrano un quadro sempre aggiornato della situazione di rischio nella rete aziendale.

 

Panoramica centralizzata

OPENVAS REPORT ti permette di acquisire e valutare con un colpo d’occhio la situazione della sicurezza della tua azienda. Grazie a una guida utente semplice e chiara, anche i dati più complessi diventano leggibili e comprensibili, accelerando così il processo decisionale in situazioni critiche.

Con opzioni di filtro flessibili e personalizzabili, OPENVAS REPORT semplifica notevolmente il lavoro quotidiano di amministratori e responsabili della sicurezza.

Interfaccia flessibile

Le ampie funzioni di esportazione consentono di integrare OPENVAS REPORT in modo ancora più approfondito nell’infrastruttura, ad esempio per elaborare dati esterni all’interno dello stesso OPENVAS REPORT.

I vantaggi in sintesi

Funzione Valore aggiunto per la vostra azienda
Visibilità completa degli asset Una panoramica completa di tutti gli asset IT e delle relative vulnerabilità in un’unica interfaccia, per una valutazione accurata e aggiornata della tua sicurezza.
Dashboard user-friendly Una dashboard interattiva e ben strutturata che rende immediatamente comprensibili anche le informazioni più complesse sulle vulnerabilità, facilitando decisioni rapide e informate.
Elaborazione flessibile dei dati Diverse opzioni di esportazione, API e automazione si integrano perfettamente nei flussi di lavoro esistenti, adattandosi alle specifiche esigenze operative.
Consolidamento efficiente dei dati Aggregazione centralizzata dei risultati provenienti da più scanner e sedi, che riduce il carico amministrativo e accelera i tempi di risposta.
Classificazione personalizzabile delle vulnerabilità Livelli di gravità e tag configurabili liberamente, per mappare con precisione i modelli interni di compliance e gestione del rischio.
Funzioni di reporting avanzate Creazione istantanea di report mirati per i dirigenti, gli audit o team: filtri e link drill-down forniscono dettagli approfonditi sui problemi di sicurezza critici.

Scopri di più

Sei interessato a una demo o desideri un’offerta personalizzata? Contatta il nostro team vendite per scoprire di più su OPENVAS REPORT. Scrivici a sales@greenbone.net oppure contattaci direttamente su. Saremo lieti di rispondere a tutte le tue domande!

Contatto Prova Ora Acquista Torna alla Panoramica

/da
Dirk Boeing

Vulnerabilità nei processori: strategie per mitigare i rischi hardware

Le falle di sicurezza informatica nell’ambito IT si presentano in diverse forme. Tra le più comuni figurano le vulnerabilità legate a software non aggiornati, password deboli, configurazioni errate e l’utilizzo di switch di rete obsoleti. Tuttavia, un tipo di esposizione che spesso genera confusione durante le scansioni riguarda le vulnerabilità hardware.

Abbiamo imparato a convivere con la continua scoperta di vulnerabilità software. Per garantire una sicurezza informatica affidabile, ormai è prassi consolidata per ogni azienda (o almeno si spera) eseguire regolarmente scansioni della rete per identificare tali vulnerabilità e applicare le relative patch. Tuttavia, non sono solo gli sviluppatori di software a commettere errori: anche i processori possono contenere difetti. Le vulnerabilità nei chip spesso derivano da errori di progettazione che permettono a malintenzionati di sfruttare effetti collaterali imprevisti per accedere a dati sensibili. A differenza delle vulnerabilità software, generalmente correggibili con patch o aggiornamenti, quelle hardware richiedono aggiornamenti del microcodice o, in alcuni casi, modifiche strutturali nei progetti futuri dei processori.

Aggiornamenti del microcodice

L’unico metodo per risolvere le vulnerabilità della CPU e continuare così a garantire la sicurezza informatica è l’applicazione di aggiornamenti del microcodice, normalmente distribuiti tramite il sistema operativo o, in alcuni casi, attraverso il firmware (UEFI/BIOS). Il microcodice rappresenta un livello software all’interno del processore che traduce i comandi di alto livello in operazioni interne specifiche.

Anche se gli utenti finali generalmente non aggiornano il microcodice autonomamente, produttori come Intel forniscono update mirati per correggere alcune vulnerabilità, evitando la necessità di sostituire completamente l’hardware. Tuttavia, tali aggiornamenti possono comportare una diminuzione delle prestazioni, poiché disattivano o modificano alcune ottimizzazioni della CPU per prevenire il rischio di sfruttamento. In alcuni casi, questo può anche causare fino a un 50% di riduzione delle prestazioni.

Vulnerabilità su più fronti

Poiché queste vulnerabilità si trovano a livello di CPU, vengono rilevate e segnalate da tool come Greenbone Enterprise Appliance. Tuttavia, questo può generare confusione, poiché gli utenti potrebbero erroneamente pensare che le vulnerabilità segnalate riguardino il sistema operativo. È fondamentale comprendere che non si tratta di falle di sicurezza informatica nel sistema operativo, ma di difetti architetturali all’interno del processore stesso.

Le vulnerabilità vengono rilevate verificando la presenza delle patch di microcodice appropriate per la CPU identificata. Ad esempio, se una scansione rileva un sistema privo dell’aggiornamento del microcodice Intel per Downfall, viene segnalato come vulnerabile. Tuttavia, questo non implica che il sistema operativo stesso sia insicuro o la sicurezza informatica in generale sia a rischio.

Performance o sicurezza?

Per gestire le vulnerabilità della CPU è sempre necessario scendere a compromessi, e gli utenti devono scegliere l’approccio più adatto alle loro esigenze per garantire una sicurezza informatica ottimale. In generale, le opzioni disponibili sono tre:

  • Applicare gli aggiornamenti del microcodice, accettando una possibile riduzione delle prestazioni, soprattutto per i carichi di lavoro ad alta intensità di calcolo.
  • Evitare alcuni aggiornamenti del microcodice, assumendosi il rischio qualora la probabilità di sfruttamento nell’ambiente in uso sia considerata bassa.
  • Sostituire l’hardware interessato con CPU non affette da queste vulnerabilità.

In ultima analisi, la scelta dipende dal caso d’uso specifico e dal livello di tolleranza al rischio dell’organizzazione o dei singoli responsabili.

Contatto Prova Ora Acquista Torna alla Panoramica

/da
Markus Feilner

Dennis-Kenji Kipker sul futuro del NIS2 in Germania ed Europa

La Germania ha affrontato da poco le elezioni politiche. Nel quadro di questi avvenimenti, l’implementazione del NIS2 nella Repubblica federale tedesca sembra essersi temporaneamente arenata. Mentre altri paesi europei sono già pronti, le aziende tedesche dovranno attendere ancora diversi mesi prima di poter contare su una certezza giuridica. E anche se il tema è già stato ampiamente discusso e preparato, il nuovo governo riparte da zero.

Abbiamo avuto il piacere di confrontarci con uno dei massimi esperti di NIS2: Dennis-Kenji Kipker, Scientific Director del cyberintelligence.institute di Francoforte sul Meno, professore presso la Riga Graduate School of Law e consulente abituale dell’Ufficio federale per la sicurezza nelle tecnologie dell’informazione (BSI), oltre che di numerose altre istituzioni pubbliche e scientifiche. 

Perché il governo federale ha scartato la bozza del NIS2?

Prof. Dr. Dennis-Kenji Kipker

Kipker: Quanto accaduto si deve al principio di discontinuità. Questo impone che, come avveniva con il precedente governo, tutti i progetti in sospeso debbano essere archiviati. “A causa delle elezioni anticipate, non è stato possibile completare la procedura parlamentare relativa al NIS2UmsuCG”. In conformità con tale principio, tutti i progetti di legge non approvati dal vecchio Bundestag devono essere ripresentati e negoziati una volta costituito il nuovo Parlamento. Di conseguenza, anche il lavoro già svolto sul NIS2 viene accantonato. Tuttavia, è possibile riprendere quanto già elaborato e proporre quasi lo stesso testo.

È probabile che accada?

Kipker: Il Ministero federale degli Interni ha elaborato un piano interno di 100 giorni per il periodo post-elettorale. Secondo fonti riservate, al suo interno la sicurezza informatica dovrebbe occupare una posizione di rilievo, con particolare enfasi sull’implementazione rapida della direttiva NIS2. Qualora si riuscisse ad attuarla prima dell’autunno/inverno 2025, anticipando le attuali previsioni, la Germania eviterebbe di trovarsi nella scomoda posizione di fanalino di coda europeo in questo ambito.

Si tratta di un obiettivo realistico?

Kipker: Nonostante il principio di discontinuità, sarebbe opportuno recuperare gran parte del lavoro svolto nella precedente legislatura. Attualmente, sembra che il Ministero dell’Interno ancora in carica miri proprio a questo obiettivo. Tuttavia, solo i politici e i funzionari direttamente coinvolti possono valutare la fattibilità di tale approccio. Considerando la complessità dell’attività politica tedesca, cento giorni appaiono un termine piuttosto ambizioso, anche con il pieno coinvolgimento di tutte le parti interessate. Sarebbe necessario effettuare un bilancio, identificare e affrontare le esigenze di revisione nell’attuale progetto NIS2UmsuCG, nonché definire e chiarire l’ambito di applicazione tedesco della legge, allineandola al diritto dell’Unione Europea. Inoltre, tra la fine del 2024 e l’inizio del 2025, anche in seguito all’audizione di esperti sul NIS2 al Bundestag, si è cercato di far approvare numerose proposte, alcune delle quali piuttosto controverse. In ogni caso, questi aspetti dovrebbero essere oggetto di una nuova negoziazione politica e di un’attenta valutazione tecnica.

Quando crede che accadrà?

Kipker: Difficile dirlo con certezza, ma se viene rispettata la scadenza dei 100 giorni, dovrebbe essere possibile completare l’implementazione nazionale della direttiva NIS2 prima dell’inverno 2025/2026. Tuttavia, si tratta solo di un’ipotesi preliminare che viene ripetutamente ventilata da “ambienti solitamente ben informati”. In ogni caso, indipendentemente dagli sforzi attuali, è probabile che la Germania finisca comunque tra i fanalini di coda nell’attuazione a livello europeo, poiché le ambizioni attuali non sembrano in grado di cambiare questa prospettiva.

E qual è la situazione in altri Paesi europei?

Kipker: Attualmente, ci sono numerosi sviluppi interessanti. È emerso, ad esempio, che le diverse implementazioni nazionali della direttiva NIS2 generano inefficienze e costi aggiuntivi per le aziende coinvolte, un fenomeno non del tutto inaspettato. Recentemente, l’Agenzia dell’Unione Europea per la Cybersecurity (ENISA) ha pubblicato un rapporto informativo che analizza e valuta il livello di maturità e la criticità dei settori rilevanti per la NIS2 nel contesto europeo. L’ENISA afferma che il “NIS360 mira ad assistere gli Stati membri e le autorità nazionali nell’identificazione delle lacune e nella definizione delle priorità per l’allocazione delle risorse”. Parallelamente, il cyberintelligence.institute ha condotto uno studio approfondito per conto dell’azienda svizzera Asea Brown Boveri, che esamina in dettaglio l’implementazione della direttiva NIS2 in tutta l’Unione Europea.

Quali sono i punti salienti di questo studio?

Kipker: Il Comparison Report si rivolge principalmente alle aziende operanti a livello transnazionale che cercano un primo punto di riferimento per la compliance in materia di sicurezza informatica. In particolare, emerge la mancanza di responsabilità amministrative centralizzate, nel senso di uno “sportello unico”, e le divergenti scadenze di attuazione creano difficoltà alle imprese. A fine gennaio, solo nove Stati membri dell’UE avevano recepito la direttiva NIS2 nel diritto nazionale, mentre per altri 18 Stati il processo legislativo era ancora in corso. Un’altra osservazione cruciale: la conformità alla NIS2 in uno Stato membro dell’UE non garantisce necessariamente la conformità in un altro Stato membro.

Insomma, la Germania non può definirsi pioniere, ma nemmeno fanalino di coda?

Kipker: Non siamo di certo in prima linea, ma se riusciremo a completare l’implementazione nazionale entro la fine dell’anno, potremmo evitare l’ultima posizione, pur rimanendo molto indietro. Allo stato attuale, la mia ipotesi è che risultati veramente resilienti si vedranno solo nell’ultimo trimestre del 2025, e allora forse saremo veramente in coda al gruppo. Spetta ai politici valutare se questa situazione possa soddisfare le nostre esigenze di cybersicurezza e resilienza digitale.

Dov’è possibile informarsi sullo stato attuale del progetto?

Kipker: Gli eventi e le opportunità di partecipazione si susseguono con regolarità. Il 18 marzo, ad esempio, è previsto un evento informativo del BSI, dove sarà possibile ottenere chiarimenti sulla pianificazione. Successivamente, nel maggio 2025, si terrà il congresso NIS-2 proprio qui vicino a Francoforte, per il quale è stato recentemente nominato il “Community Leader NIS-2 più autorevole”. Sicuramente l’evento offrirà spunti informativi interessanti. In ogni caso, non esitate a contattarmi per qualsiasi domanda riguardante NIS2!

Contatto Prova Ora Acquista Torna alla Panoramica

/da
Joseph Lee

Threat Report febbraio 2025: minacce latenti

Le minacce informatiche si stanno evolvendo rapidamente, ma le vulnerabilità sfruttate dagli attaccanti rimangono pressoché invariate. Per il 2025, molti analisti hanno fornito una retrospettiva sul 2024 e una previsione per l’anno a venire. Gli attacchi informatici diventano sempre più costosi per le aziende, ma le cause restano invariate. Il phishing [T1566] e lo sfruttamento di vulnerabilità software note [T1190] continuano a essere le principali minacce. È interessante notare che gli attaccanti stanno diventando sempre più veloci nel trasformare le informazioni pubbliche in armi, convertendo le rivelazioni di CVE (Common Vulnerabilities and Exposures) in codice exploit utilizzabile nel giro di pochi giorni o addirittura ore. Una volta penetrati nella rete di una vittima, gli aggressori eseguono i loro obiettivi con maggiore rapidità nella seconda fase, implementando il ransomware in tempi molto brevi.

In questo Threat Report, analizziamo le recenti rivelazioni sul gruppo ransomware Black Basta e le misure di protezione offerte da Greenbone. Esamineremo inoltre un rapporto di GreyNoise sullo sfruttamento di massa delle vulnerabilità, una nuova falla critica nella Zimbra Collaboration Suite e le minacce emergenti per i dispositivi di edge networking.

L’era delle tecnologie sismiche

Se le crisi di sicurezza informatica sono paragonabili a terremoti, l’ecosistema tecnologico globale rappresenta le placche tettoniche sottostanti. Questo sistema può essere efficacemente descritto come il corrispettivo informatico del periodo Paleozoico nella storia geologica terrestre. Le dinamiche competitive e le spinte innovative del mercato esercitano pressioni contrastanti sull’infrastruttura della cybersecurity, simili alle forze che portarono alla collisione dei supercontinenti di Pangea. Queste sollecitazioni continue generano “scosse” ricorrenti che provocano riassestamenti strutturali permanenti, modificando radicalmente il panorama della sicurezza digitale.

I nuovi paradigmi informatici come l’IA generativa e l’informatica quantistica offrono vantaggi significativi ma comportano anche rischi considerevoli. La corsa all’accesso ai dati personali sensibili da parte di governi e giganti tecnologici amplifica i rischi per la privacy e la sicurezza dei cittadini. L’impatto di queste lotte tecnologiche sulla sfera privata, la sicurezza e non da ultimo la società, è profondo e multiforme. Ecco alcune delle forze principali che destabilizzano attualmente la sicurezza informatica:

  • L’evoluzione rapida delle tecnologie guida l’innovazione e impone cambiamenti tecnologici continui.
  • Le aziende si trovano costrette ad adattarsi sia per la svalutazione di tecnologie e standard obsoleti, sia per mantenere la propria competitività sul mercato.
  • La concorrenza serrata accelera lo sviluppo dei prodotti e accorcia i cicli di rilascio.
  • L’obsolescenza programmata si è affermata come strategia aziendale per generare maggiori profitti.
  • La diffusa mancanza di responsabilità da parte dei fornitori di software ha portato a privilegiare le prestazioni rispetto al principio “Security First”.
  • Inoltre, gli stati nazionali impiegano tecnologie avanzate per condurre operazioni di guerra cibernetica, guerra dell’informazione e guerra elettronica.

Grazie a queste forze, i criminali informatici ben equipaggiati e organizzati trovano un numero praticamente illimitato di falle di sicurezza da sfruttare. Il Paleozoico è durato 300 milioni di anni; speriamo di non dover attendere altrettanto affinché i produttori di prodotti dimostrino responsabilità e adottino principi di progettazione sicura [1][2][3] per prevenire i cosiddetti punti deboli “imperdonabili” causati dalla negligenza [4][5]. Le aziende devono quindi sviluppare una flessibilità tecnica e implementare programmi efficienti per la gestione delle patch. Una gestione continua e prioritaria delle vulnerabilità è imprescindibile.

Greenbone contro Black Basta

I log di chat interni trapelati del gruppo ransomware Black Basta offrono uno sguardo senza precedenti sulle tattiche e i processi operativi del gruppo. La pubblicazione di questi verbali, attribuita a un individuo noto come “ExploitWhispers”, sarebbe una ritorsione contro gli attacchi controversi di Black Basta alle banche russe, che avrebbero scatenato conflitti interni al gruppo. Dall’inizio delle sue attività nell’aprile 2022, Black Basta ha dimostrato di essere un attore di spicco nel panorama del cybercrime, accumulando oltre 100 milioni di dollari in pagamenti di riscatto da più di 300 vittime a livello globale. Un’analisi approfondita dei documenti trapelati ha rivelato riferimenti a 62 CVE che illustrano le strategie del gruppo per sfruttare vulnerabilità note. Greenbone dispone di test di rilevamento per 61 di questi CVE, coprendo così il 98% delle vulnerabilità menzionate.

Il report di GreyNoise sullo sfruttamento massivo delle vulnerabilità

Gli attacchi di mass-exploitation sono operazioni automatizzate che prendono di mira i servizi di rete accessibili via Internet. Questo mese, GreyNoise ha pubblicato un rapporto dettagliato che analizza il panorama delle mass-exploitation, evidenziando i 20 principali CVE attaccati dalle botnet più estese (in termini di IP univoci) e i fornitori dei prodotti più frequentemente presi di mira. Inoltre, elenca i principali CVE inseriti nel catalogo KEV (Known Exploited Vulnerabilities) della CISA sfruttati dalle botnet Il Greenbone Enterprise Feed offre test di riconoscimento per l’86% di tutti i CVE (86 in tutto) menzionati nel report. Se si considerano solo CVE pubblicati nel 2020 o successivamente (66 in totale), il nostro Enterprise Feed ne copre il 90%.

Inoltre:

  • Il 60% dei CVE sfruttati negli attacchi di massa sono stati pubblicati nel 2020 o successivamente.
  • Gli attaccanti sono sempre più veloci nello sfruttare le nuove vulnerabilità, iniziando ad utilizzarle entro poche ore dalla loro pubblicazione.
  • Il 28% delle vulnerabilità presenti nel catalogo KEV della CISA viene attivamente sfruttato dai gruppi ransomware.

La Zimbra Collaboration Suite

Il CVE-2023-34192 (CVSS 9.0) è una vulnerabilità di cross-site scripting (XSS) critica nella Zimbra Collaboration Suite (ZCS) versione 8.8.15. Questa falla permette a un attaccante autenticato remoto di eseguire codice arbitrario attraverso uno script manipolato indirizzato alla funzione “/h/autoSaveDraft”. La CISA ha incluso il CVE-2023-34192 nel suo catalogo KEV, indicando che la vulnerabilità è stata attivamente sfruttata in attacchi reali. Il codice exploit PoC (Proof of Concept) è disponibile pubblicamente, rendendo possibile anche agli aggressori meno esperti di sfruttare la vulnerabilità. Fin dalla sua scoperta nel 2023, il CVE-2023-34192 ha mantenuto un punteggio EPSS molto elevato. Per i difensori che utilizzano l’EPSS (Exploit Prediction Scoring System) per prioritizzare le azioni correttive, questo implica la necessità di applicare patch con la massima urgenza.

Zimbra Collaboration Suite (ZCS) è una piattaforma open source per applicazioni da ufficio che combina e-mail, calendari, contatti, gestione delle attività e strumenti di collaborazione. Ciononostante, ZCS detiene una quota di mercato di nicchia, rappresentando meno dell’1% di tutte le piattaforme di posta elettronica e messaggistica.

Vivere sul filo del rasoio: vulnerabilità critiche nei dispositivi di rete

Nel nostro threat report mensile, abbiamo evidenziato la persistente vulnerabilità dei dispositivi di rete edge. All’inizio del mese, abbiamo documentato le gravi conseguenze derivanti dai modelli di router e firewall Zyxel giunti a fine ciclo di vita. In questa sezione, esaminiamo i nuovi rischi per la sicurezza che rientrano nella categoria “Edge Networking”. È importante sottolineare che Greenbone offre capacità di rilevamento per tutti i CVE discussi di seguito.

Hacker cinesi sfruttano PAN-OS di Palo Alto per attacchi ransomware

Il CVE-2024-0012 (CVSS 9.8), una vulnerabilità scoperta in Palo Alto PAN-OS nel novembre 2023, si è affermata come una delle più sfruttate del 2024. Fonti attendibili riportano che attori di minacce cinesi, presumibilmente supportati dal governo, stanno sfruttando questa falla per orchestrare attacchi ransomware. Recentemente, è emersa un’altra grave vulnerabilità che affligge PAN-OS: CVE-2025-0108 (CVSS 9.1). Annunciata questo mese, la CISA l’ha immediatamente classificata come attivamente sfruttata. Questa falla permette di aggirare l’autenticazione nell’interfaccia di gestione web. Particolarmente preoccupante è la possibilità di combinarla con CVE-2024-9474 (CVSS 7.2), una vulnerabilità distinta che consente l’escalation dei privilegi, consentendo a un attaccante non autenticato di ottenere il controllo completo sui file root di un dispositivo PAN-OS non aggiornato.

SonicWall corregge una vulnerabilità critica attivamente sfruttata in SonicOS

CVE-2024-53704, una vulnerabilità critica negli apparecchi SonicWall è stata recentemente inclusa nel catalogo KEV della CISA. Sorprendentemente, la CISA ha segnalato che questa è solo una delle otto vulnerabilità legate a SonicWall attivamente sfruttate negli attacchi ransomware. La nuova minaccia CVE-2024-53704 (CVSS 9.8) è una vulnerabilità creata da un meccanismo di autenticazione non pulito [CWE-287] in SSLVPN delle versioni SonicOS 7.1.1-7058 e precedenti, 7.1.2-7019 e 8.0.0-8035 di SonicWall. Consente agli aggressori di bypassare l’autenticazione e dirottare le sessioni VPN SSL attive, ottenendo potenzialmente l’accesso non autorizzato alla rete. Un’analisi tecnica completa è disponibile su BishopFox. Un Security Advisory di SonicWall menziona anche altri CVE ad alta gravità in SonicOS che sono stati patchati insieme a CVE-2024-53704.

CyberoamOS e firewall XG di Sophos a fine vita attivamente sfruttati

Il fornitore di sicurezza Sophos, che ha acquisito Cyberoam nel 2014, ha emesso un avviso e una patch per CVE-2020-29574. CyberoamOS fa parte dell’ecosistema dei prodotti Sophos. Oltre a questo CVE, anche il Sophos XG Firewall, che sta per scadere, è oggetto di un avviso di possibile sfruttamento attivo.

  • CVE-2020-29574 (CVSS 9.8 ): una vulnerabilità critica di SQL Injection [CWE-89] rilevata nell’interfaccia WebAdmin delle versioni CyberoamOS fino al 4 dicembre 2020. Questa falla consente agli aggressori non autenticati di eseguire da remoto istruzioni SQL arbitrarie, con la possibilità di ottenere l’accesso amministrativo completo al dispositivo. È stata rilasciata una patch hotfix che si applica anche a determinati prodotti End-of-Life (EOL) interessati.
  • CVE-2020-15069 (CVSS 9.8) è una vulnerabilità critica di overflow del buffer che colpisce le versioni di Sophos XG Firewall da 17.x a v17.5 MR12. Questa falla consente l’esecuzione di codice remoto (RCE) non autenticata attraverso la funzione di segnalibro HTTP/S per l’accesso clientless. Sebbene pubblicata nel 2020, la vulnerabilità è ora oggetto di sfruttamento attivo ed è stata inclusa nel catalogo KEV della CISA, indicando un incremento del rischio associato. In risposta alla scoperta della vulnerabilità nel 2020, Sophos ha prontamente emesso un avviso e rilasciato un hotfix per i firewall interessati. È importante notare che le appliance hardware della serie XG raggiungeranno la fine del loro ciclo di vita (EOL) il 31 marzo 2025.

Escalation di privilegi e bypass dell’autenticazione in Fortinet FortiOS e FortiProxy

Fortinet ha reso nota l’esistenza di due vulnerabilità critiche che interessano FortiOS e FortiProxy. In risposta il Canadian Center for Cybersecurity e il Belgian Center for Cybersecurity hanno emesso degli avvisi. Fortinet ha confermato che CVE-2024-55591 è oggetto di sfruttamento attivo e ha rilasciato una guida ufficiale contenente informazioni dettagliate sulle versioni colpite e sugli aggiornamenti raccomandati.

  • CVE-2024-55591 (CVSS 9.8 ): una vulnerabilità di bypass dell’autenticazione che sfrutta un percorso o canale alternativo [CWE-288] in FortiOS. Questa falla permette a un attaccante remoto di ottenere privilegi di super amministratore attraverso richieste appositamente create al modulo Node.js Websocket. La disponibilità di molteplici exploit (PoC) [1][2] incrementa significativamente il rischio di sfruttamento, rendendo la vulnerabilità accessibile anche ad aggressori con minori competenze tecniche.
  • CVE-2024-40591 (CVSS 8.8 ): permette a un amministratore autenticato con autorizzazioni Security Fabric di elevare i propri privilegi a super amministratore. Questo avviene collegando il dispositivo FortiGate bersaglio a un FortiGate upstream compromesso sotto il controllo dell’attaccante.

Vulnerabilità Cisco come vettori di accesso iniziale negli attacchi a Telekom

Negli ultimi mesi, il gruppo di spionaggio cinese Salt Typhoon ha regolarmente sfruttato almeno due vulnerabilità critiche nei dispositivi Cisco IOS XE per ottenere un accesso permanente alle reti di telecomunicazione. Le vittime includono ISP italiani, una società di telecomunicazioni sudafricana e una grande azienda thailandese, oltre a dodici università in tutto il mondo, tra cui l’UCLA, l’Universitas Negeri Malang indonesiana e l’UNAM messicana. In passato, Salt Typhoon aveva già preso di mira almeno nove società di telecomunicazioni statunitensi, tra cui Verizon, AT&T e Lumen Technologies. Secondo le autorità statunitensi, l’obiettivo principale del gruppo è la sorveglianza di persone di alto rango, personalità politiche e funzionari legati agli interessi politici cinesi.

I CVE sfruttati da Salt Typhoon includono:

  • CVE-2023-20198 (CVSS 10 ): una vulnerabilità di estensione dei privilegi nell’interfaccia web di Cisco IOS XE. Questa falla viene utilizzata per ottenere l’accesso iniziale, consentendo agli aggressori di creare un account amministratore.
  • CVE-2023-20273 (CVSS 7.2 ): un altro punto debole che facilita l’estensione dei privilegi. Dopo aver ottenuto l’accesso come amministratore, questa vulnerabilità viene sfruttata per ampliare l’accesso privilegiato ai file root e configurare un tunnel GRE (Generic Routing Encapsulation) per garantire una permanenza duratura nella rete.

Inoltre, nel febbraio 2025 sono stati resi noti altri due CVE nei prodotti Cisco:

  • CVE-2023-20118 (CVSS 7.2 ): una vulnerabilità di Command Injection nell’interfaccia di gestione basata sul web dei router Cisco Small Business consente agli aggressori autenticati e remoti di eseguire qualsiasi comando con privilegi di root inviando richieste http manipolate.
  • La CISA ha incluso CVE-2023-20118 nel suo catalogo RIC, suggerendo che la vulnerabilità è attivamente sfruttata.
  • CVE-2023-20026 (CVSS 7.2 ): una vulnerabilità di Command Injection nell’interfaccia di gestione basata sul web dei router Cisco Small Business serie RV042 consente agli aggressori remoti autenticati con credenziali amministrative valide di eseguire qualsiasi comando sul dispositivo.
  • La vulnerabilità è dovuta a una convalida impropria degli input dell’utente nei pacchetti http in entrata. Sebbene non sia noto che CVE-2023-20026 venga sfruttato nelle campagne attive, il Product Security Incident Response Team (PSIRT) di Cisco è a conoscenza che esiste un codice di exploit PoC per questa vulnerabilità.

Ivanti corregge quattro vulnerabilità critiche

Sono state identificate quattro vulnerabilità critiche che colpiscono Ivanti Connect Secure (ICS), Policy Secure (IPS) e Cloud Services Application (CSA). Al momento, non sono state riportate evidenze di attacchi attivi in natura o di exploit Proof of Concept. Ivanti raccomanda vivamente agli utenti di procedere immediatamente all’aggiornamento alle versioni più recenti per mitigare queste gravi falle di sicurezza.

Ecco un breve riassunto tecnico:

  • CVE-2025-22467 (CVSS 8.8): un overflow del buffer basato su stack [CWE-121] nelle versioni ICS antecedenti alla 22.7R2.6 permette agli aggressori autenticati di ottenere l’esecuzione di codice remoto (RCE).
  • CVE-2024-38657 (CVSS 9.1): un controllo esterno del nome del file nelle versioni ICS precedenti alla 22.7R2.4 e IPS precedenti alla 22.7R1.3 consente agli aggressori autenticati di scrivere file arbitrari.
  • CVE-2024-10644 (CVSS 9.1): una vulnerabilità di code injection in ICS (pre-22.7R2.4) e IPS (pre-22.7R1.3) permette agli amministratori autenticati di eseguire qualsiasi RCE.
  • CVE-2024-47908 (CVSS 7.2): una falla di Command Injection del sistema operativo [CWE-78] nella console web di amministrazione di CSA (versioni precedenti alla 5.0.5) consente agli amministratori autenticati di eseguire qualsiasi RCE.

Per riassumere

Il Threat Report di febbraio 2025 evidenzia sviluppi significativi nel panorama della cybersecurity, focalizzandosi sulle tattiche in rapida evoluzione di gruppi ransomware come Black Basta e sulla persistente minaccia critica ai dispositivi di rete edge. Potenziati da strumenti di intelligenza artificiale, gli aggressori sfruttano le vulnerabilità con crescente rapidità, talvolta entro poche ore dalla loro scoperta. Per contrastare queste minacce emergenti, le aziende devono mantenere un alto livello di vigilanza, implementando misure di sicurezza proattive, aggiornando costantemente le proprie difese e utilizzando efficacemente i dati sulle minacce per anticipare i nuovi vettori di attacco.

Contatto Prova Ora Acquista Torna alla Panoramica

/da
Joseph Lee

Threat Report gennaio 2025: farsi trovare preparati conviene

Quest’anno, numerose grandi aziende di tutto il mondo si troveranno a dover affrontare le conseguenze di attacchi informatici. Molte vulnerabilità conosciute costituiscono canali privilegiati per accedere a risorse di rete sensibili. Nel nostro primo Threat Report del 2025 analizziamo le principali violazioni del 2024, oltre ai data breach più importanti di gennaio 2025.

Un dato interessante: le vulnerabilità qui riportate rappresentano solo la punta dell’iceberg. A gennaio 2025 sono state pubblicate oltre 4.000 nuove CVE (Common Vulnerabilities and Exposures), di cui 22 hanno ottenuto un punteggio CVSS massimo di 10 e 375 e sono quindi considerate ad alto rischio. La crescente ondata di vulnerabilità critiche in dispositivi di edge networking persiste, con nuove falle scoperte nei prodotti di aziende leader del settore tecnologico come Microsoft, Apple, Cisco, Fortinet, Palo Alto Networks, Ivanti e Oracle. Queste esposizioni sono state aggiunte al catalogo KEV (Known Exploited Vulnerabilities) della CISA (Cybersecurity and Infrastructure Security Agency).

Mitigazione dei rischi nella supply chain: responsabilità condivise

Nell’era digitale, la dipendenza quotidiana da software di terze parti rende imprescindibile un rapporto di fiducia con questi strumenti. Tuttavia, quando questa fiducia viene compromessa, sia per negligenza, intenti malevoli o errori umani, la responsabilità della sicurezza informatica grava inevitabilmente sull’utente finale. La capacità di mitigare i rischi è strettamente legata alle competenze tecniche e alla collaborazione tra le parti coinvolte. Nel 2025, i professionisti della cybersecurity devono essere pienamente consapevoli di questa complessa realtà.

In caso di compromissione della sicurezza nella catena di approvvigionamento, condurre un’indagine approfondita sulle cause scatenanti diventa un imperativo. Valuta se il fornitore del software ha messo a disposizione gli strumenti necessari per gestire autonomamente i risultati delle tue misure di sicurezza. È necessario valutare se il fornitore del software ha reso disponibili gli strumenti essenziali per gestire in autonomia i risultati delle misure di sicurezza adottate. Inoltre, occorre verificare che i responsabili della sicurezza informatica sanno identificare ed eliminare le vulnerabilità. Oppure se i dipendenti sono stati adeguatamente formati per riconoscere gli attacchi di phishing e se sono state implementate altre misure di cybersecurity appropriate. Le aziende devono rafforzare le proprie difese contro i ransomware, valutando regolarmente il rischio e dando priorità alla gestione delle patch. Infine, devono verificare l’esistenza di strategie di backup affidabili che soddisfino gli obiettivi di recupero e implementare ulteriori controlli di sicurezza di base per salvaguardare i dati sensibili e prevenire interruzioni operative.

La soluzione? L’approccio proattivo

Il report annuale 2024 del National Cyber Security Center britannico offre un quadro preoccupante: il numero di attacchi informatici significativi è triplicato rispetto al 2023. Parallelamente, il CSIS (Center for Strategic and International Studies) ha pubblicato un elenco dettagliato dei principali incidenti informatici del 2024, fornendo una visione d’insieme del panorama globale delle minacce. Il conflitto Russia-Ucraina ha contribuito a influenzare questo scenario. Inoltre, la rapida transizione globale da cooperazione internazionale a una crescente ostilità ha ulteriormente aggravato i rischi, delineando un contesto sempre più complesso e instabile.

Secondo il rapporto di sicurezza 2024 di Check Point Research, il 96% delle vulnerabilità sfruttate nel 2024 aveva più di un anno. Questo dato risulta incoraggiante per i difensori proattivi, perché dimostra che le aziende che adottano un approccio di gestione delle vulnerabilità sono meglio preparate contro attacchi ransomware mirati e attacchi di massa. Una cosa è chiara: la sicurezza informatica proattiva si rivela fondamentale nel ridurre i costi associati alle violazioni della sicurezza.

Analizziamo due delle violazioni della sicurezza più significative del 2024:

  • La violazione dei dati di Change Healthcare: nonostante una generale diminuzione delle violazioni nel settore sanitario rispetto al picco del 2023, l’attacco ransomware contro Change Healthcare ha stabilito un nuovo primato, coinvolgendo 190 milioni di persone. I costi associati hanno raggiunto la cifra astronomica di 2,457 miliardi di dollari. In seguito all’incidente, lo stato del Nebraska ha intrapreso un’azione legale contro l’azienda, accusandola di gestire sistemi IT obsoleti non conformi agli standard di sicurezza aziendali. Secondo le stime di IBM, le violazioni nel settore sanitario sono le più onerose, con un costo medio di 9,77 milioni di dollari nel 2024.
  • I Typhoon fanno irruzione nelle aziende americane: il suffisso “Typhoon” è utilizzato nella nomenclatura di Microsoft per indicare gruppi di minacce di origine cinese. Il gruppo cinese Salt Typhoon, sostenuto dallo stato, si è infiltrato nelle reti di almeno nove grandi società di telecomunicazioni statunitensi, ottenendo accesso ai metadati delle chiamate e dei messaggi degli utenti, nonché alle registrazioni audio di alti funzionari governativi. Volt Typhoon ha compromesso le reti di Singapore Telecommunications (SingTel) e di altri operatori di telecomunicazioni a livello globale. Questi gruppi hanno sfruttato vulnerabilità in dispositivi di rete obsoleti, inclusi server Microsoft Exchange non aggiornati, router Cisco, firewall Fortinet e Sophos, e applicazioni VPN Ivanti. Greenbone è in grado di rilevare tutte le vulnerabilità software note associate agli attacchi di Salt Typhoon e Volt Typhoon.
    [1][2].

Il Regno Unito e il divieto alle organizzazioni pubbliche di pagare riscatti ransomware

Nell’ambito della lotta al ransomware, il governo britannico ha proposto di vietare alle organizzazioni pubbliche e alle infrastrutture critiche il pagamento di riscatti con l’obiettivo di disincentivare i criminali informatici dal prenderle di mira. Tuttavia, un recente rapporto  del National Audit Office (NAO) sottolinea che “la minaccia informatica per il governo del Regno Unito è grave e in rapida evoluzione”.

L’FBI, la CISA e l’NSA sconsigliano il pagamento dei riscatti in caso di attacchi ransomware. Pagare non garantisce il recupero dei dati crittografati né impedisce la diffusione di informazioni sottratte; al contrario, potrebbe incentivare ulteriori attività criminali. D’altro canto, secondo alcune analisi, molte piccole e medie imprese potrebbero non essere in grado di sostenere finanziariamente i tempi di inattività causati da un attacco ransomware. Questo solleva un dilemma: è accettabile che i criminali informatici traggano profitto, mentre le risorse che potrebbero essere destinate allo sviluppo di talenti locali vengono invece utilizzate per pagare riscatti?

Vulnerabilità in SonicWall SMA 1000 sfruttata in modo attivo

Microsoft Threat Intelligence ha scoperto che la vulnerabilità CVE-2025-23006 con un punteggio di 9.8 (Critico)  secondo il Common Vulnerability Scoring System (CVSS), è attivamente sfruttata nei gateway SonicWall SMA 1000. Questa falla deriva dalla deserializzazione  [CWE-502] di dati non affidabili. Un aggressore remoto non autenticato con accesso alle console di gestione Appliance Management Console (AMC) e Central Management Console (CMC) potrebbe eseguire comandi arbitrari sul sistema operativo del dispositivo. SonicWall ha rilasciato l’hotfix versione 12.4.3-02854 per risolvere questa vulnerabilità.

Sebbene non sia stato identificato alcun codice exploit pubblicamente disponibile, numerose agenzie governative hanno emesso avvisi riguardanti la vulnerabilità CVE-2025-23006, tra cui la Confederazione tedesca BSI CERT, il Centro canadese per la sicurezza informatica, il CISA e il NHS (National Health Service) del Regno Unito. Greenbone è in grado di rilevare sistemi SonicWall interessati da questa vulnerabilità verificando da remoto la versione indicata nel banner di servizio.

CVE-2024-44243 per rootkit persistenti in macOS

Gennaio 2025 è stato un mese pieno di sfide per la sicurezza Apple. Microsoft Threat Intelligence ha condotto un test di sicurezza su macOS, individuando una vulnerabilità che potrebbe consentire alle applicazioni installate di alterare il System Integrity Protection (SIP) del sistema operativo. Questa falla potrebbe permettere agli aggressori di installare rootkit e malware persistenti, nonché di eludere Transparency, Consent and Control (TCC), il meccanismo che gestisce i permessi di accesso delle applicazioni alle cartelle. Nonostante l’assenza di segnalazioni di attacchi attivi, Microsoft ha reso disponibili dettagli tecnici sulla vulnerabilità.

Alla fine di gennaio 2025, sono stati identificati 88 nuovi CVE, di cui 17 con livello di gravità critica (CVSS), che interessano l’intera gamma di prodotti Apple. Una di queste, CVE-2025-24085, è stata rilevata in attacchi attivi ed è stata aggiunta al catalogo KEV della CISA. Inoltre, sono state scoperte due vulnerabilità potenzialmente sfruttabili nei chip delle serie M di Apple, denominate SLAP e FLOP, per le quali non sono ancora stati assegnati CVE. Con SLAP i ricercatori hanno sfruttato le vulnerabilità del chip per manipolare le tecniche di allocazione dell’heap nel Safari WebKit e alterare i metadati delle stringhe JavaScript. Questo ha permesso loro di eseguire letture speculative fuori dai limiti, estraendo contenuti sensibili del DOM da altre schede del browser. Per quanto riguarda FLOP, gli esperti hanno dimostrato che è possibile rubare dati sensibili da Safari e Google Chrome bypassando la verifica del tipo JavaScript nel Safari WebKit e l’isolamento del sito in Chrome tramite WebAssembly.

Inoltre, sono state identificate cinque vulnerabilità critiche che interessano Microsoft Office per macOS, tutte con potenziali exploit che potrebbero portare all’esecuzione remota di codice (RCE). I prodotti coinvolti includono Microsoft Word (CVE-2025-21363), Excel (CVE-2025-21354 e CVE-2025-21362) e OneNote (CVE-2025-21402) per macOS. Sebbene al momento manchino dettagli tecnici specifici su queste vulnerabilità, è altamente consigliato aggiornare i software interessati il prima possibile per mitigare i rischi associati.

Il Greenbone Enterprise Feed rileva gli aggiornamenti di sicurezza mancanti per macOS e identifica numerose vulnerabilità (CVE) che interessano le applicazioni macOS, inclusi i cinque CVE recentemente scoperti in Microsoft Office per Mac.

6 vulnerabilità in Rsync consentono la compromissione di server e client

La combinazione die due vulnerabilità recentemente identificate può consentire l’esecuzione remota di codice su server Rsyncd vulnerabili, mantenendo un accesso anonimo in sola lettura. CVE-2024-12084, è un overflow del buffer heap e CVE-2024-12085 riguarda una perdita di informazioni. I mirror pubblici che utilizzano Rsyncd sono particolarmente a rischio, poiché non dispongono di propri controlli di accesso.

Inoltre, i ricercatori hanno rilevato che un server Rsyncd compromesso può leggere e scrivere qualsiasi file sui client collegati, consentendo il furto di informazioni sensibili e, potenzialmente, l’esecuzione di codice dannoso attraverso la modifica di file eseguibili.

Ecco un riepilogo delle nuove vulnerabilità, ordinate per gravità CVSS:

  • CVE-2024-12084 (CVSS 9.8 Critical): una gestione impropria della lunghezza del checksum può causare un overflow del buffer heap, portando potenzialmente all’esecuzione remota di codice.
  • CVE-2024-12085 (CVSS 7.5 High): la presenza di contenuti non inizializzati nello stack può esporre informazioni sensibili.
  • CVE-2024-12087 (CVSS 6.5 Medium): la vulnerabilità Path Traversal in Rsync consente di accedere a file non autorizzati sul client.
  • CVE-2024-12088 (CVSS 6.5 High): la vulnerabilità di Path Traversal attraverso l’opzione –safe-links può consentire la scrittura arbitraria di file al di fuori della directory prevista.
  • CVE-2024-12086 (CVSS 6.1 High): i server Rsync possono esporre file sensibili dei client durante le operazioni di copia, potenzialmente rivelando dati riservati.
  • CVE-2024-12747 (CVSS 5.6 High): una gestione inadeguata dei collegamenti simbolici in Rsync può causare una condizione di gara che, se sfruttata, consente l’escalation dei privilegi quando un utente malintenzionato controlla il processo Rsyncd.

Nel complesso, queste vulnerabilità rappresentano un serio rischio di esecuzione di codice remoto (RCE), esfiltrazione di dati e installazione di malware persistenti sia sui server Rsyncd che su client ignari.Gli utenti devono installare la patch di Rsync, eseguire una scansione approfondita degli Indicators of Compromise (IoC) su tutti i sistemi che hanno utilizzato Rsync e, se necessario, rivedere l’infrastruttura per la condivisione dei file. Greenbone è in grado di rilevare tutte le vulnerabilità note in Rsync e di identificare l’assenza di aggiornamenti di sicurezza critici.

CVE-2025-0411: 7-Zip consente l’aggiramento di MotW

Il 25 gennaio 2025 è stata resa nota la vulnerabilità CVE-2025-0411 (punteggio CVSS 7.5 – High), che interessa il software di archiviazione 7-Zip. Questa falla permette di aggirare il meccanismo di sicurezza “Mark of the Web” (MotW) di Windows tramite archivi appositamente predisposti. MotW contrassegna i file scaricati da Internet con un identificatore di zona (ADS), avvisando l’utente quando alcuni contenuti sono potenzialmente non sicuri. Tuttavia, nelle versioni di 7-Zip precedenti alla 24.09, il meccanismo MotW veniva eliminato nei file estratti da tali archivi, esponendo il sistema a rischi. Per sfruttare questa vulnerabilità, un attaccante necessita dell’interazione dell’utente, che dovrebbe aprire un archivio infetto e successivamente eseguire un file dannoso in esso contenuto.

Una ricerca di Cofense  ha rilevato che i siti web governativi di tutto il mondo vengono utilizzati in modo improprio tramite CVE-2024-25608, una vulnerabilità nella piattaforma digitale Liferay che viene sfruttata per il credential phishing, malware e operazioni di comando e controllo (C2). Questa falla consente agli aggressori di reindirizzare gli utenti da URL .gov affidabili verso siti di phishing malevoli. La combinazione dei reindirizzamenti da domini .gov con la vulnerabilità di 7-Zip presenta il rischio elevato per la diffusione nascosta di malware.

Per mitigare questa vulnerabilità, è essenziale aggiornare manualmente 7-Zip alla versione 24.09, disponibile dalla fine del 2024. Come accennato nell’introduzione, la sicurezza della supply chain del software spesso si colloca in una zona grigia, poiché tutti dipendiamo da software al di fuori del nostro controllo. È interessante notare che, prima della divulgazione della vulnerabilità CVE-2025-0411, 7-Zip non aveva avvisato gli utenti riguardo a tale problema. Sebbene 7-Zip sia un software open source, il repository Github del prodotto non fornisce dettagli o informazioni di contatto per una divulgazione responsabile.

Inoltre, la vulnerabilità CVE-2025-0411 ha attivato notifiche da parte di DFN-CERT e BSI CERT-Bund[1][2]. Greenbone è in grado di individuare le versioni vulnerabili di 7-Zip.

Per riassumere

Questa edizione del nostro report mensile sulle minacce informatiche si concentra su significative violazioni della sicurezza avvenute nel 2024 e sulle nuove vulnerabilità critiche scoperte a gennaio 2025. La supply chain del software rappresenta un rischio crescente per aziende di ogni dimensione e interessa sia prodotti open source che proprietari. Tuttavia, il software open source offre trasparenza e la possibilità per le parti interessate di impegnarsi proattivamente per migliorare la sicurezza tramite un approccio collaborativo o indipendente. Sebbene i costi della sicurezza informatica siano elevati, il progresso delle competenze tecniche diventerà sempre più un fattore decisivo per la protezione di aziende e stati. La fortuna sta dalla parte di chi si fa trovare preparato.

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
Greenbone AG

I prodotti Greenbone Enterprise nella lista dei migliori vulnerability scanner

OpenVAS nasce nel 2005 quando Nessus passa da una licenza open source a una proprietaria. Le aziende Intevation e DN Systems prendono in mano il progetto già in corso per mantenerlo e svilupparlo con una licenza GPL v2.0. Da allora OpenVAS ha preso il nome di Greenbone, la soluzione di scansione e gestione delle vulnerabilità open source più conosciuta e usata al mondo. Con la Greenbone Community Edition offriamo una versione di gratuita per gli sviluppatori, di cui siamo molto orogliosi. Inoltre, abbiamo creato una una gamma di soluzioni aziendali a pagamento che confluiscono nel Greenbone Enterprise Feed per il settore pubblico e privato.

Greenbone è pioniere del settore della cybersecurity e pur conoscendo le tattiche di marketing di alcune aziende di cybersecurity resta fedele ai propri obiettivi: condividere informazioni veritiere sui suoi prodotti e su quello che i suoi vulnerability test sono veramente in grado di fare. Non nascondiamo che siamo rimasti molto sorpresi quando abbiamo letto un report di benchmark (in inglese) pubblicato nel 2024 dalla concorrenza, in cui venivano presi in esame i principali scanner di vulnerabilità.

Greenbone è un sistema di scansione delle vulnerabilità open source conosciuto in tutto il mondo; quindi, va da sé che fosse stato incluso nell’elenco dei migliori. Tuttavia, anche se ci ha fatto piacere essere presi in considerazione per il test, alcune informazioni riportate ci hanno lasciati perplessi. Così abbiamo deciso di scrivere questo articolo per mettere alcune cose in chiaro ed esaminare i vari punti nel dettaglio.

I risultati del report di benchmark 2024

Il report di benchmark 2024 a cura di Pentest-Tools ha stilato una classifica dei principali sistemi di scansione delle vulnerabilità in base a due criteri: Detection Availability (disponibilità di rilevamento), cioè i CVE individuati da ogni sistema con appositi test, e Detection Accuracy (accuratezza di rilevamento), ovvero il grado di efficacia di questi test.

Il report ha messo a confronto la Community Edition gratuita di Greenbone e il Greenbone Community Feed con prodotti aziendali di altri fornitori: Qualys, Rapid7, Tenable, Nuclei, Nmap e il prodotto offerto da Pentest-Tools. Greenbone ha conquistato il 5° posto per Detection Availability e si è avvicinata al 4° per Detection Accuracy. Tutto sommato non male rispetto ai giganti del settore della cybersicurezza.

L’unico problema è che, come abbiamo detto prima, anche Greenbone offre un prodotto aziendale, che è stato escluso dalla classifica. Eseguendo il confronto con Greenbone Enterprise Feed invece che con la versione gratuita, Greenbone vince davvero a mani basse.

Ecco come stanno le cose veramente

Grafico a barre del benchmark 2024 dei sistemi di scansione delle vulnerabilità di rete: Greenbone Enterprise al primo posto per disponibilità e accuratezza di rilevamento, rispetto a strumenti come Pentest-Tools, Nessus, Rapid7, Qualys, Nmap, Nuclei e Greenbone Community.

Greenbone Enterprise è in testa alla classifica dei sistemi di scansione delle vulnerabilità.

 

Enterprise Feed è in testa alla classifica nell’ambito Detection Availability

I risultati delle nostre ricerche, che possono essere verificati nel nostro SecInfo Portal, indicano che Greenbone Enterprise Feed ha test di individuazione per 129 dei 164 CVE compresi nel test. Questo significa che la Detection Availability del nostro prodotto Enterprise supera addirittura del 70,5% quanto riportato nel resto, facendoci balzare nettamente in testa alla classifica.

Ci teniamo a chiarire che non abbiamo aggiunto i test di Greenbone Enterprise Feed dopo l’uscita del report. Greenbone aggiorna i Community ed Enterprise Feed ogni giorno e spesso siamo i primi a rilasciare test di vulnerabilità quando viene pubblicato un CVE. Un’analisi della nostra copertura dei test di vulnerabilità dimostra che questi sono sempre stati disponibili.

La nostra Detection Accuracy è stata ampiamente sottovalutata

C’è un altro aspetto da considerare: Greenbone è diverso dagli altri sistemi di scansione. Il modo con cui è progettato gli procura i vantaggi che lo rendono una delle soluzioni più apprezzate nel settore. Ad esempio, il nostro sistema di scansione si può controllare tramite API, così gli utenti possono sviluppare i propri tool e gestire tutte le funzionalità di Greenbone come preferiscono. Inoltre, noi usiamo il filtro Quality of Detection (QoD, qualità di rilevamento) che non esiste nella maggior parte dei sistemi di scansione delle vulnerabilità.

Chi ha compilato il report ha indicato di aver semplicemente utilizzato la configurazione predefinita di ogni sistema. Ma dato che il filtro QoD Greenbone non è stato applicato in modo corretto, il test di confronto non ha valutato in maniera equa il vero livello di rilevamento CVE di Greenbone. Tenendo in considerazione questi aspetti, Greenbone conquista di nuovo la classifica, con una stima di 112 CVE su 164.

Per ricapitolare

Ci fa molto piacere che Greenbone Community Edition sia arrivato al 5° posto per Detection Availability e a un passo dal 4° per Detection Accuracy in un confronto pubblicato nel 2024 sui sistemi di scansione delle vulnerabilità delle reti, ma questi risultati non tengono conto delle reali capacità di Greenbone Enterprise Feed. A rigor di logica, nell’elenco sarebbe dovuto comparire il nostro prodotto Enterprise. La classifica, infatti, comprendeva soluzioni aziendali di altri fornitori, non prodotti gratuiti come la nostra Community Edition.

Ricalcolata la Detection Availability di Greenbone alla luce di Enterprise Feed, questa arriva a 129 CVE sui 164 testati e supera del 70,5% il risultato precedente. Inoltre, le impostazioni predefinite non tengono conto della funzionalità Quality of Detection (QoD, qualità di rilevamento) di Greenbone. Se si tiene conto di queste imprecisioni, Greenbone conquista il gradino più alto del podio. È il sistema di scansione della vulnerabilità open source più utilizzato al mondo e continua a essere il migliore per copertura delle vulnerabilità, pubblicazione rapida dei test di vulnerabilità e vere e proprie funzionalità di livello aziendale, come architettura API flessibile, filtri avanzati e punteggi QoD.

Contatto Prova Ora Acquista Torna alla Panoramica

/da
Joseph Lee

Quali sono i KPI del vulnerability managament e come misurarli

Il successo di ogni azienda si fonda su attività strategiche e operative imprescindibili. I controlli di sicurezza sono studiati per proteggere tali attività e assicurare la continuità delle operazioni aziendali e il raggiungimento degli obiettivi strategici. Tuttavia, un approccio statico, basato sul principio “install and forget”, offre scarse garanzie di protezione. Nell’attuale panorama digitale anche una singola falla di sicurezza può causare violazioni di dati con conseguenze significative. Problemi come il , la proliferazione dei server ed errori di configurazione tendono a proliferare come erbacce. Senza un monitoraggio continuo, i team di sicurezza rischiano di non individuare queste problematiche, lasciando agli aggressori l’opportunità di sfruttarle. Per questo motivo, i framework di sicurezza informatica devono essere concepiti come processi iterativi, che includano monitoraggio continuo, audit regolari e miglioramenti costanti.

I responsabili della sicurezza dovrebbero chiedersi: cosa deve misurare la nostra organizzazione per garantire una sicurezza efficace e favorire il miglioramento continuo? In questo articolo esamineremo da vicino la logica degli indicatori chiave di performance (KPI) nella sicurezza informatica, così come delineata da leader del settore come NIST e SANS Institute, e presenteremo un set di KPI specifici per la gestione delle vulnerabilità. I KPI di base possono essere un punto di partenza per le organizzazioni che avviano un programma di gestione delle vulnerabilità, mentre le metriche avanzate offrono maggiore trasparenza per quelle con programmi già consolidati.

Come i KPI di sicurezza informatica supportano i principali obiettivi aziendali

Gli indicatori chiave di performance (KPI) vengono generati attraverso la raccolta e l’analisi di dati sulle prestazioni rilevanti e sono fondamentali per due obiettivi strategici principali. Il primo è facilitare il processo decisionale basato sull’evidenza. Ad esempio, i KPI possono fornire ai responsabili informazioni per valutare le prestazioni dei programmi di gestione delle vulnerabilità, determinare il livello di raggiunto e decidere se allocare ulteriori risorse o mantenere lo status quo.

Il secondo obiettivo è promuovere la responsabilità nelle attività di sicurezza. I KPI aiutano a identificare le cause di prestazioni insufficienti e a fornire avvisi tempestivi in caso di controlli di sicurezza inadeguati o mal implementati. Monitorando correttamente le prestazioni della gestione delle vulnerabilità, è possibile valutare l’efficacia delle procedure esistenti, apportare eventuali correzioni o integrare controlli aggiuntivi. Inoltre, i dati raccolti per creare i KPI possono dimostrare la conformità a politiche interne, standard di sicurezza obbligatori o volontari, nonché leggi e regolamenti applicabili, offrendo una solida base per le attività di sicurezza informatica.

L’ambito di misurazione dei KPI può estendersi all’intera azienda oppure concentrarsi su specifici reparti o infrastrutture essenziali per le operazioni aziendali. Questo ambito può essere adattato progressivamente con la maturazione di un programma di sicurezza informatica. Nelle fasi iniziali di implementazione della gestione delle vulnerabilità, le informazioni disponibili potrebbero essere limitate a dati di base, sufficienti per definire metriche KPI iniziali.

Con il progredire del programma, tuttavia, la raccolta dei dati diventa più strutturata e consente di sviluppare KPI più sofisticati. Per le organizzazioni esposte a rischi elevati, misure più avanzate possono risultare necessarie per garantire una visibilità ottimale.

Tipi di misure di sicurezza informatica

Il framework NIST SP 800-55 V1 (e il precedente NIST SP 800-55 r2) identifica tre categorie principali di misure di sicurezza da sviluppare e registrare:

  • Misure di attuazione: valutano l’implementazione delle politiche di sicurezza e il progresso delle relative attività. Esempi includono il numero totale di sistemi informativi sottoposti a scansione e la percentuale di sistemi critici analizzati per rilevare vulnerabilità.
  • Misure di efficacia/efficienza: monitorano i risultati delle attività di sicurezza e valutano i processi a livello di programma e di sistema. Queste misure indicano se i controlli di sicurezza sono implementati correttamente, funzionano come previsto e raggiungono gli obiettivi prefissati. Ad esempio, la percentuale di vulnerabilità critiche identificate e mitigate nell’infrastruttura critica operativa.
  • Misure di impatto: quantificano le implicazioni aziendali delle attività di sicurezza, come i risparmi sui costi, le spese sostenute per risolvere vulnerabilità di sicurezza o altri effetti rilevanti legati alla protezione delle informazioni.

Principali indicatori per la gestione delle vulnerabilità

La gestione delle vulnerabilità si concentra sull’identificazione e sull’eliminazione delle vulnerabilità note. Pertanto, i KPI più rilevanti sono quelli che offrono informazioni su questi due aspetti. Inoltre, valutare l’efficacia di uno specifico tool di gestione delle vulnerabilità può aiutare a comparare diversi prodotti. Poiché questi rappresentano i metodi più logici per analizzare le attività di gestione delle vulnerabilità, abbiamo suddiviso i KPI in tre categorie principali. Ogni elemento include anche tag che evidenziano quale scopo, tra quelli definiti nel NIST SP 800-55, la metrica soddisfa.

Sebbene il seguente elenco non sia esaustivo, di seguito riportiamo alcuni KPI rilevanti per valutare le prestazioni nella gestione delle vulnerabilità:

Indicatori di performance per il rilevamento

  • Estensione della scansione (implementazione): misura la percentuale delle risorse totali di un’organizzazione sottoposte a scansione per rilevare vulnerabilità. Questo indicatore è cruciale nelle prime fasi di attuazione del programma per definire obiettivi e monitorare la maturità del programma nel tempo. Può anche aiutare a identificare lacune non identificate nell’infrastruttura IT, che potrebbero rappresentare rischi significativi.
  • Mean time to detect (MTTD) (efficienza): calcola il tempo medio intercorrente tra la pubblicazione delle informazioni su una vulnerabilità e il momento in cui un controllo di sicurezza la rileva. Miglioramenti possono essere ottenuti regolando la frequenza di aggiornamento dei moduli dello scanner di vulnerabilità o aumentando la periodicità delle scansioni.
  • Rapporto di vulnerabilità non identificate (efficacia): rappresenta il rapporto tra le vulnerabilità rilevate proattivamente tramite scansioni e quelle scoperte in seguito a incidenti o analisi post-mortem. Più alto è il rapporto, più la capacità di rilevamento proattivo è efficace.
  • Tasso di rilevamento automatizzato (efficienza): misura la percentuale di vulnerabilità identificate attraverso strumenti automatizzati rispetto ai metodi manuali. Un maggiore utilizzo dell’automazione può migliorare coerenza e rapidità nel rilevamento.

Indicatori correttivi di performance

  • Mean time to remediate (MTTR; efficienza): misura il tempo medio necessario per correggere le vulnerabilità dopo il rilevamento. Monitorare il MTTR aiuta a valutare la reattività alle minacce e il rischio derivante dal tempo di esposizione. Un MTTR più breve indica solitamente un approccio di sicurezza più rapido e agile.
  • Remediation coverage (efficacia): rappresenta la percentuale di vulnerabilità rilevate che sono state risolte con successo. È un indicatore essenziale dell’efficacia dei team di sicurezza nel mitigare i rischi. La copertura può essere personalizzata per riflettere la chiusura di vulnerabilità critiche o ad alta gravità, consentendo di concentrare gli sforzi sulle minacce più pericolose.
  • Riduzione del punteggio di rischio (impatto): misura l’impatto delle attività di gestione delle vulnerabilità sul rischio complessivo. Monitorando le variazioni del punteggio di rischio, è possibile valutare quanto efficacemente vengono gestite le minacce. Questo KPI si basa spesso su strumenti di valutazione del rischio che contestualizzano il profilo di rischio specifico dell’infrastruttura IT di un’organizzazione.
  • Tasso di conformità (impatto): indica la percentuale di sistemi conformi a normative, standard, o politiche interne di sicurezza. È un KPI essenziale per dimostrare la conformità alle parti interessate e per avvertire se non vengono soddisfatti i requisiti, minimizzando così il rischio di sanzioni e migliorando la postura di sicurezza.
  • Tasso di riapertura delle vulnerabilità (efficienza): misura la percentuale di vulnerabilità che vengono riaperte dopo essere state contrassegnate come risolte. Un basso tasso di riapertura riflette una maggiore efficacia delle misure correttive e la qualità degli interventi di mitigazione.
  • Costo della risoluzione (impatto): calcola il costo totale associato alla risoluzione delle vulnerabilità, includendo spese dirette e indirette. Analizzare i costi aiuta nella pianificazione del budget e nell’allocazione delle risorse, valutando il tempo e l’impegno richiesti per rilevare e correggere le vulnerabilità.

Indicatori sull’efficacia degli scanner di vulnerabilità

  • Tasso di rilevamento di positivi reali (efficacia): misura la percentuale di vulnerabilità reali rilevate con precisione da uno strumento. Questa metrica consente di valutare la copertura effettiva dello scanner e di confrontare diversi prodotti in base al loro valore relativo. Un tasso di rilevamento più elevato indica uno strumento altamente preciso e affidabile.
  • Tasso di rilevamento di falsi positivi (efficacia): misura la frequenza con cui lo strumento identifica erroneamente vulnerabilità inesistenti. Un tasso elevato di falsi positivi può comportare uno spreco di risorse, mentre uno basso riflette maggiore affidabilità. Questa metrica è essenziale per garantire che lo strumento sia coerente con i requisiti operativi e non generi allarmi inutili.

Conclusioni

Generando e analizzando gli indicatori chiave di prestazione (KPI), le organizzazioni possono soddisfare i requisiti fondamentali di sicurezza informatica per un monitoraggio e un miglioramento continuo. I KPI supportano anche strategie di core business come il processo decisionale e la responsabilità basati sull’evidenza.

Con una visione quantitativa dei processi di gestione delle vulnerabilità, le organizzazioni possono valutare meglio i progressi e comprendere con maggiore precisione la loro posizione di rischio per la sicurezza informatica. Aggregando un insieme appropriato di KPI, è possibile monitorare la maturità delle attività di gestione delle vulnerabilità, identificare le lacune nei controlli, nelle politiche e nelle procedure che limitano l’efficacia e l’efficienza delle correzioni, garantendo l’allineamento con i requisiti di rischio interni e con standard, leggi e regolamenti di sicurezza pertinenti.

Fonti

National Institute of Standards and Technology. Measurement Guide for Information Security: Volume 1 — Identifying and Selecting Measures. NIST, gennaio 2024, https://csrc.nist.gov/pubs/sp/800/55/v1/ipd

National Institute of Standards and Technology. Performance Measurement Guide for Information Security, Revision 2. NIST, novembre 2022, https://csrc.nist.gov/pubs/sp/800/55/r2/iwd

National Institute of Standards and Technology. Assessing Security and Privacy Controls in Information Systems and Organizations Revision 5. NIST, gennaio 2022, https://csrc.nist.gov/pubs/sp/800/53/a/r5/final

National Institute of Standards and Technology. Guide for Conducting Risk Assessments Revision 1. NIST, settembre 2012, https://csrc.nist.gov/pubs/sp/800/30/r1/final

National Institute of Standards and Technology. Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology Revision 4. NIST, aprile 2022, https://csrc.nist.gov/pubs/sp/800/40/r4/final

SANS Institute. Report di SANS del 2021: Making Visibility Definable and Measurable. SANS Institute, giugno 2021, https://www.sans.org/webcasts/2021-report-making-visibility-definable-measurable-119120/

SANS Institute. A Guide to Security Metrics. SANS Institute, giugno 2006, https://www.sans.org/white-papers/55/

Contatto Prova Ora Acquista Torna alla Panoramica

/da