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.

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

Stop ai crash di sistema: Greenbone protegge dagli attacchi DoS

Un servizio essenziale smette di funzionare, un’applicazione non risponde più o l’accesso al proprio sistema si blocca: ecco quello che può succedere durante un attacco DoS (Denial of Service). Gli attacchi DoS hanno un obiettivo chiaro e letale, ad esempio paralizzare le risorse digitali impedendo agli utenti di accedervi o provocare un crash totale. Le conseguenze possono essere molto gravi: da periodi di fermo a interruzioni del servizio fino a perdite economiche e rischi importanti per tutto l’ente o l’azienda.

Gli attacchi DoS sono ormai da molti anni e comportano conseguenze gravi per aziende, e . Si utilizzano anche in molto sofisticate o per ed estorcere loro del denaro. Ma cosa si nasconde dietro a questi attacchi e come proteggersi?

Una minaccia in costante crescita

Esistono vari modi per provocare un attacco Dos. Ad esempio, gli hacker possono usare un accesso non autorizzato e bloccare il sistema [T1529], oppure possono sfruttare falle nella logica dell’applicazione per mandare in crash il sistema da remoto o sovraccaricare la rete con traffico eccessivo per esaurire le risorse. Bloccare l’accesso agli account [T1531], distruggere i dati [T1485] o avviare un ransomware [T1486] sono altri metodi a disposizione per ostacolare ulteriormente il ripristino del sistema [T1490] o distrarre da altri attacchi chi è già impegnato nella difesa. Al contempo, il blocco dei servizi critici comporta un aumento delle vulnerabilità e nuovi attacchi informatici: se un antivirus smette di funzionare, i malware possono entrare indisturbati nella rete. Se i servizi di backup non funzionano, diventa impossibile ripristinare completamente il sistema dopo un attacco ransomware. Insomma: un circolo vizioso.

Spesso gli attacchi DoS sfruttano esposizioni già note

Spesso gli attacchi DoS sfruttano le vulnerabilità presenti nelle specifiche dei protocolli di rete, nelle implementazioni scorrette dei protocolli, nella logica errata delle applicazioni software o nelle configurazioni errate. Alcune falle a livello software che spianano la strada agli attacchi DoS sono:

  • Consumo di risorse fuori controllo
  • Buffer overflow
  • Memory leak
  • Gestione scorretta degli errori
  • Consumo asimmetrico di risorse (amplificazione)
  • Impossibilità di rilasciare una risorsa dopo l’uso

Quando i fornitori si accorgono di vulnerabilità del genere, si affrettano a creare delle patch. Ma solo gli utenti che le installano sono protetti. Scansionando le superfici della rete e dell’host che potrebbero subire un attacco, i responsabili IT possono conoscere il rischio di attacchi DoS e altri tipi di vulnerabilità. Una volta ricevuta l’informazione, chi difende può agire applicando gli aggiornamenti o modificando le configurazioni che presentano falle di sicurezza.

Tipologie di attacchi DoS

Gli attacchi DoS possono utilizzare una serie di tecniche diverse, ad esempio intasare le reti con traffico eccessivo, sfruttare le vulnerabilità dei software o manipolare funzioni a livello di applicazione. Capire il funzionamento e l’impatto potenziale degli attacchi DoS è essenziale affinché enti e aziende sviluppino strategie di difesa complete e riducano l’insorgere di questi problemi.

Le categorie principali di attacchi DoS comprendono:

  • Attacchi DoS volumetrici: gli attacchi DoS volumetrici sovraccaricano la banda di rete o le risorse di computazione come CPU e RAM con volumi elevati di traffico, impedendo così alla rete di svolgere la sua normale funzione.
  • Attacchi DoS a livello di applicazione e protocollo: questi attacchi si concentrano sulle vulnerabilità all’interno delle applicazioni software o dei protocolli di rete che potrebbero trovarsi in qualunque strato dello stack protocollare. Gli hacker sfruttano le falle nelle specifiche di protocollo, nella logica errata dell’applicazione e nelle configurazioni di sistema per destabilizzare o mandare in crash l’obiettivo.
  • Attacchi DoS di amplificazione: gli attacchi di amplificazione sfruttano protocolli specifici che generano una risposta maggiore rispetto alla richiesta iniziale. Gli hacker inviano query di piccole dimensioni al target che risponde con pacchetti grandi. Questa tattica amplifica di molto l’impatto sulla vittima che può arrivare a 100 volte le dimensioni della richiesta iniziale.
  • Attacchi DoS di riflessione: il cybercriminale invia una richiesta a un servizio, ma sostituisce l’indirizzo IP sorgente con quello della vittima. Il server invia quindi la risposta alla vittima, “riflettendo” come in uno specchio le richieste costruite dall’hacker. Di solito gli attacchi di riflessione fanno affidamento sull’UDP (User Datagram Protocol) a causa della sua natura priva di connessioni. Rispetto ai servizi TCP (Transmission Control Protocol), quelli UDP non verificano automaticamente l’indirizzo IP sorgente dei dati che ricevono.
  • Attacchi DoS delocalizzati (DDos): gli attacchi DDos sfruttano grandi gruppi di dispositivi compromessi (chiamati spesso ) per inviare quantità smisurate di traffico a un obiettivo. Le botnet sono composte da server web hackerati o router SOHO (Small Office, Home Office) sparsi in tutto il mondo e sono controllate a livello centrale da chi mette in atto la minaccia informatica. La natura delocalizzata degli attacchi DDoS li rende più difficile da mitigare perché il traffico nocivo proviene da numerosi indirizzi IP diversi. In questo modo diventa difficile distinguere gli utenti legittimi e impossibile bloccare il grande numero di indirizzi IP univoci delle botnet.

Greenbone contro i crash di sistema

Le agenzie governative di cybersecurity di tutti i paesi NATO, come , Stati Uniti e Canada segnalano che il vulnerability management è una priorità per difendersi dagli attacchi DoS. Greenbone scansiona le vulnerabilità note, aiutando così a escludere gli attacchi DoS e identificando anche i casi in cui l’errore umano contribuisce al problema rilevando configurazioni errate ed effettuando controlli dei benchmark CIS. Inoltre, Greenbone aggiorna ogni giorno i propri test di vulnerabilità e aiuta così a individuare le vulnerabilità più recenti che consentono agli attacchi DoS di andare a buon fine.

Greenbone comprende test di vulnerabilità nella categoria Denial of Service. Anche altri gruppi di test comprendono l’identificazione DoS come: database DoS test, web application DoS test, web server DoS test, Windows DoS test [1][2] e il rilevamento DoS specifico per molti prodotti di reti aziendali come Cisco, F5, Juniper Networks, Palo Alto e altri ancora. Con Greenbone che scansiona le tue reti e gli endpoint, hai accesso a più di 4.900 test in grado di rilevare falle DoS.

Inoltre, quando la protezione Greenbone’s “Safe Checks” per una scan configuration è disabilitata, il nostro sistema di scansione esegue attacchi attivi simulati come quelli DoS di amplificazione. Questi test comportano maggiori rischi, come l’aumento della probabilità di un’interruzione di servizio, per cui la funzionalità Safe Checks è abilitata di default in modo che questa serie estesa di scansioni invasive sia eseguita solo se configurata appositamente.

Anche se nessun sistema di mitigazione del rischio informatico è in grado di garantire una protezione completa da tutti gli attacchi DoS (ad esempio attacchi DDoS volumetrici), sicuramente identificare e mitigare in modo proattivo le esposizioni note permette di chiudere le falle che renderebbero un sistema un bersaglio facile. Eliminando le vulnerabilità conosciute dall’infrastruttura IT, un’azienda o un ente possono inoltre evitare di diventare parte del problema: spesso le strutture IT già infette sono usate dagli hacker per ulteriori attacchi DDoS contro terzi.

Riassunto

Gli attacchi DoS (Denial of Service) puntano a mettere fuori uso i sistemi IT sovraccaricandoli di traffico o sfruttano vulnerabilità note a livello software. Greenbone offre soluzioni complete di vulnerability assessment che identificano punti di entrata potenziali per gli attacchi DoS e consentono così a enti e aziende di rafforzare le proprie difese e minimizzare i rischi. Con una gestione proattiva delle vulnerabilità e un monitoraggio continuo, Greenbone aiuta imprese e organismi a individuare e mitigare l’impatto di attacchi DoS potenzialmente devastanti.

Contatto Prova Ora Acquista Torna alla Panoramica

/da
Greenbone AG

Comprendere cosa sono gli attacchi di mass exploitation

Quando un’organizzazione ha un volume d’affari e quindi un valore elevato, si può stare sicuri che criminali cercheranno di sfruttare le sue debolezze informatiche per ricavarne un guadagno economico. Fra le minacce più gravi troviamo gli , che bloccano i dati della vittima e richiedono il pagamento di un riscatto per fornire una chiave di decrittazione. Le organizzazioni devono identificare con precisione dove si nascondo i rischi e proteggere al meglio le risorse critiche. Tuttavia, anche le realtà più piccole dotate di infrastruttura IT possono beneficiare di un assessment della loro superficie di attacco che gli consenta di mitigare le vulnerabilità.

Gli attacchi di mass exploitation sono campagne automatizzate che scansionano continuamente l’Internet pubblico per individuare bersagli facili. Gli attacchi sono eseguiti dai bot in modo automatizzato e su ampia scala. Una volta compromesse, le risorse violate vengono sfruttate per attività illecite. Secondo CloudFlare, il è generato da bot dannosi, mentre altri report stimano che questo ammonti addirittura al . Una volta compromesse, le risorse violate vengono sfruttate per attività illecite.

Cosa accade alle risorse compromesse da campagne di mass exploitation?

Quando un aggressore ottiene il controllo di un sistema, stima il valore delle risorse compromesse e decide come ricavarne un ritorno economico. Il è un ecosistema sotterraneo che alimenta il mercato della criminalità informatica. Qui, i cosiddetti Initial Access Brokers (IAB) vendono accessi non autorizzati a gruppi di Ransomware as a Service (RaaS) specializzati in questo tipo di crimine informatico. Gli IAB usano gli accessi per criptare i dati delle vittime e chiedere riscatti.

Gli attacchi di mass exploitation sono solo uno dei tanti metodi usati dagli IAB. Se le risorse compromesse presentano un valore estorsivo limitato, spesso entrano a fare parte di reti “botnet zombie”, usati per scansionare Internet alla ricerca di altre vulnerabilità. In alternativa, i sistemi infetti possono inviare , ospitare o servire come infrastruttura di comando e controllo per favorire attacchi più complessi.

Come funzionano gli attacchi di mass exploitation

Analizzando le campagne di mass exploitation attraverso le tattiche, tecniche e procedure usate nel framework MITRE ATT&CK, possiamo comprendere meglio il comportamento degli hacker. Se ancora non conosci MITRE ATT&CK, questo è un buon momento per familiarizzare con la MITRE ATT&CK Enterprise Matrix, poiché è uno strumento utile per capire come operano gli aggressori.

Gli attacchi di mass exploitation prendono di mira un gran numero di sistemi utilizzando strumenti avanzati. Questi strumenti scansionano automaticamente numerosi indirizzi IP e lanciano attacchi informatici non appena rilevano una vulnerabilità. Gli aggressori si concentrano soprattutto su software esposti a Internet, come quelli che gestiscono siti web o consentono l’accesso remoto ai server.

Di seguito spieghiamo come funzionano gli attacchi di mass exploitation:

  • Ricognizione [TA0043]: gli aggressori raccolgono informazioni su vulnerabilità note da fonti pubbliche come il database NIST NVD dove sono elencate le CVE con dettagli tecnici e punteggi di gravità. Inoltre, possono reperire codice exploit da fonti come exploit-db o GitHub, oppure acquistare strumenti dannosi sui mercati del dark web. In alcuni casi, sviluppano exploit personalizzati.
  • Preparazione [TA0042]: gli aggressori creano strumenti in grado di identificare e sfruttare automaticamente le vulnerabilità [T1190] nei sistemi bersaglio senza necessità di intervento umano.
  • Scansione attiva [T1595]: gli aggressori eseguono scansioni su larga scala per individuare servizi vulnerabili e le loro versioni [002]. Questo processo somiglia a quello utilizzato dai difensori informatici per scansionare la propria infrastruttura alla ricerca di vulnerabilità. Tuttavia, invece di correggere le debolezze individuate, gli aggressori le analizzano per pianificare come sfruttarle al meglio.
  • Attacco: una volta trovata una vulnerabilità, gli strumenti tentano di sfruttarla per ottenere il controllo remoto del sistema [TA0011] o causare un Denial of Service (DoS) [T1499]. Gli attacchi possono sfruttare diverse debolezze del software, tra cui credenziali di account predefinite [CWE-1392], SQL injection [CWE-89], buffer overflow [CWE-119], caricamento di file non autorizzati [CWE-434] o controlli di accesso inadeguati [CWE-284].
  • Valutazione e azione [TA0040]: dopo la compromissione, gli aggressori decidono come utilizzare il sistema compromesso a loro vantaggio. Possono eseguire ulteriori ricognizioni, spostarsi lateralmente nella rete [TA0008], rubare dati [TA0010], distribuire ransomware [T1486] o vendere l’accesso ad altri criminali informatici [T1650].

Come difendersi dagli attacchi di mass exploitation

Per proteggersi dagli attacchi di mass exploitation è fondamentale adottare un approccio proattivo. Le potenziali vulnerabilità devono essere identificate e risolte prima che gli aggressori possano sfruttarle. Questo richiede l’implementazione di solide pratiche di sicurezza informatica, tra cui valutazioni regolari, monitoraggio continuo e una rapida risposta alle esposizioni rilevate.

Ecco alcune misure chiave per proteggersi:

  • Creare un inventario delle risorse IT: stila un elenco completo di tutti i dispositivi hardware, software e di rete utilizzati nell’organizzazione. Un inventario accurato consente di non trascurare alcun sistema durante le valutazioni di rischio e la gestione delle patch.
  • Eseguire valutazioni del rischio: dai priorità agli asset in base alla loro importanza per le operazioni aziendali. Conducendo regolarmente valutazioni del rischio fari in modo che le minacce più critiche vengano affrontate, riducendo le probabilità di violazioni significative.
  • Scansionare regolarmente le risorse e correggere le vulnerabilità: esegui scansioni di vulnerabilità su tutte le risorse IT, concentrandoti su quelle esposte a Internet o che presentano un rischio elevato. Applica rapidamente le patch o altre misure di mitigazione per evitare attacchi. Monitora e misura i progressi fatti nella gestione delle vulnerabilità.
  • Eliminare servizi e applicazioni non in uso: riduci la superficie di attacco rimuovendo software e servizi non utilizzati. Meno elementi attivi ci sono, meno opportunità avranno gli aggressori di sfruttare le vulnerabilità.
  • Formazione del personale: promuovi una cultura della sicurezza con corsi di formazione regolari. La consapevolezza aiuta a prevenire attacchi di phishing e malspam, riducendo il rischio per l’organizzazione.
  • Utilizzare soluzione anti-malware: spesso i malware sono distribuiti mediante campagne di malspam e phishing su larga scala. Assicurati che tutti i sistemi dispongano di software antivirus aggiornati e filtri antispam attivi per individuare e mettere in quarantena file infetti.
  • Implementare robuste politiche di autenticazione: gli attacchi di credential stuffing sono spesso componenti automatizzati delle campagne di mass exploitation. Proteggi gli account con password forti generate in modo casuale e non riutilizzarle su più piattaforme. Rafforza la sicurezza con autenticazione a più fattori (MFA), password manager e politiche di rotazione regolari.
  • Configurare firewall e sistemi IPS: utilizza firewall e sistemi di prevenzione delle intrusioni (IPS) per bloccare il traffico dannoso. Imposta regole rigorose per proteggere i servizi sensibili ed effettua verifiche periodiche per aggiornare le configurazioni in base alle nuove minacce. 

Conclusione

Il mass exploitation si riferisce a campagne di attacco informatico automatizzate che sfruttano bot per scansionare la rete pubblica in cerca di sistemi vulnerabili. Questi attacchi colpiscono un’ampia gamma di vittime, approfittando di vulnerabilità note nei software esposti a Internet. Una volta compromessi, i sistemi vengono utilizzati per scopi malevoli come: lanciare attacchi ransomware, vendere accessi non autorizzati ad altri gruppi criminali, ampliare botnet per attacchi futuri.

Questa tecnica rappresenta una minaccia significativa poiché consente agli aggressori di operare su larga scala con uno sforzo minimo.

Per proteggersi dal mass exploitation le organizzazioni devono adottare un approccio proattivo, implementando misure di sicurezza fondamentali come: scansioni regolari delle vulnerabilità, gestione tempestiva delle patch, controllo rigoroso degli accessi, monitoraggio continuo della rete. Infine, investire nella formazione del personale in materia di sicurezza informatica può ridurre significativamente il rischio di cadere vittima di queste campagne.

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

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
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
Elmar Geese

IA e cybersecurity: la promessa dell’intelligenza artificiale

In che modo l’intelligenza artificiale (AI) sta trasformando la sicurezza informatica? Questa tecnologia renderà il mondo digitale più sicuro o lo esporrà a nuovi rischi? Questi interrogativi sono stati al centro di una stimolante discussione alla “Conferenza di Potsdam per la Sicurezza Informatica Nazionale 2024”. Ho avuto il privilegio di esplorarli insieme alla Prof.ssa Sandra Wachter, al Dr. Kim Nguyen e al Dr. Sven Herpig. L’IA mantiene le promesse? E, soprattutto, quali sviluppi possiamo aspettarci dal futuro??

HPI Security Panel
La cybersecurity è già di per sé una sfida complessa per aziende e istituzioni. L’introduzione dell’intelligenza artificiale (AI) la renderà più pericolosa o contribuirà a una protezione più efficace dei sistemi IT? Cosa sappiamo al riguardo? Quali sono le questioni principali da considerare? Le opportunità economiche e i rischi sociali legati all’AI sono al centro dell’attenzione pubblica e delle normative in fase di sviluppo. La legge sull’intelligenza artificiale dell’UE riflette sia le speranze che i timori associati a questa tecnologia emergente.

Speranze e paure legate all’intelligenza artificiale

Le speranze legate all’intelligenza artificiale includono la possibilità di risolvere sfide tecniche precedentemente irrisolvibili, accelerando i processi aziendali e produttivi e consentendo alle macchine di gestire autonomamente compiti sempre più complessi. In ambito militare, l’IA ha il potenziale di offrire protezioni uniche, salvando vite umane attraverso sistemi di difesa avanzati come l’Iron Dome, che utilizzano l’intelligenza artificiale per rilevare e neutralizzare minacce in tempo reale.

D’altra parte, l’IA presenta un lato oscuro fatto di minacce come la manipolazione di massa tramite deepfake, attacchi di phishing sempre più sofisticati oltre al timore che possa rubare posti di lavoro, tipica di ogni innovazione tecnologica. I chatbot stanno sostituendo gli operatori di servizio, i generatori di immagini stanno rimpiazzando i fotografi e i grafici, i generatori di testo mettono alla prova giornalisti e autori, mentre la musica generata dall’IA mette in ombra musicisti e compositori. In quasi tutte le professioni emerge il timore di essere rimpiazzati, persino nel settore IT, un tempo sinonimo di opportunità lavorative abbondanti e sicure. Queste paure, seppur spesso giustificate, a volte si rivelano esagerate o infondate.

Nell’ambito della cybersecurity resta incerto quanto l’IA possa effettivamente migliorare la sicurezza e sostituire gli esperti o le soluzioni esistenti. Questa incertezza riguarda sia gli aggressori che i difensori. La disparità è evidente: i difensori devono colmare il maggior numero possibile di lacune, mentre agli aggressori basta una sola vulnerabilità per sferrare un attacco efficace. Fortunatamente, i difensori possono affidarsi a strumenti che automatizzano molte attività, indispensabili per fronteggiare le minacce. Tuttavia, l’IA non fornisce ancora un supporto adeguato, come dimostrano i danni crescenti causati da attacchi informatici tradizionali, nonostante l’adozione di difese basate sull’IA. Parallelamente, cresce la percezione che l’IA stia rendendo gli aggressori sempre più potenti e minacciosi.

Per migliorare la sicurezza informatica, dobbiamo approfondire l’analisi e ottenere una visione più chiara e dettagliata dei fatti.

A che punto siamo oggi?

Finora non sappiamo nulla di attacchi informatici tecnici generati dall’intelligenza artificiale. Attualmente, non ci sono casi rilevanti e verificabili, solo scenari teoricamente costruiti. La situazione potrebbe cambiare, ma la situazione attuale è questa. Al momento, non conosciamo alcuna IA in grado di generare attacchi sufficientemente sofisticati. Sappiamo, però, che il phishing è molto facile da implementare con modelli linguistici generativi e che e-mail di spam e phishing risultano più abili, almeno aneddoticamente. Non sappiamo se questo causa più danni rispetto al già considerevole impatto attuale. Attualmente la situazione è già abbastanza grave, anche senza IA. Tuttavia, il phishing è solo il primo passo per accedere a una vulnerabilità.

Elmar Geese, membro del consiglio di amministrazione di Greenbone, alla Conferenza di Potsdam per la sicurezza informatica nazionale presso l’Hasso-Plattner-Institute (HPI), foto:  Nicole Krüger

Come proteggerci?

La buona notizia è che una vulnerabilità sfruttata può quasi sempre essere individuata e risolta in anticipo. Così, anche il miglior attacco basato su IA generativa non porterebbe a nulla. Ed è così che bisogna fare. Perché, se oggi sono minacciato da un attacco convenzionale o domani dall’intelligenza artificiale nella mia rete, una vulnerabilità nel software o nella configurazione di sicurezza sarà comunque sempre necessaria affinché l’attacco abbia successo. Due strategie offrono quindi la migliore protezione: in primo luogo, essere preparati al peggio, per esempio grazie a backup e la capacità di ripristinare tempestivamente i sistemi. La seconda è individuare le lacune ogni giorno e chiuderle prima che possano essere sfruttate. Una regola empirica semplice: ogni lacuna esistente può e sarà sfruttata. 

Ruolo e caratteristiche dell’IA

I sistemi di intelligenza artificiale sono di per sé ottimi bersagli per gli attacchi. Proprio come Internet, non sono stati progettati pensando alla “sicurezza by design”. Sono semplici software e hardware, proprio come qualsiasi altro sistema. La differenza principale è che, a differenza dei sistemi IT convenzionali, la cui funzionalità può essere compresa con uno sforzo adeguato, i sistemi AI non possono essere “rattoppati” come durante un intervento chirurgico. Se un modello linguistico non sa cosa fare, non genera uno stato o un messaggio di errore, ma ha le “allucinazioni”. Tuttavia, “avere le allucinazioni” è solo un termine figurato per descrivere situazioni in cui il sistema mente, indovina, inventa o compie azioni strane. Questo tipo di errore non può essere corretto facilmente, ma richiede una riqualificazione del sistema, spesso senza una causa chiara dell’errore stesso.

Se l’errore è evidente e l’IA confonde ad esempio i cani con i pesci, è relativamente facile riconoscere il problema. Tuttavia, se l’IA deve determinare la probabilità di aver rilevato un’anomalia pericolosa o innocua, ad esempio su un’immagine a raggi X, la situazione diventa più complessa. Non è raro che i prodotti basati su IA vengano ritirati perché l’errore non è correggibile. Un esempio significativo è stato Tay, una chatbot lanciata da Microsoft, il cui tentativo di uso è fallito due volte.

Cosa possiamo imparare da tutto questo? Ridurre le aspettative, concentrandosi su funzioni di IA semplici e ben definite, è spesso la chiave per ottenere risultati concreti. Ecco perché molte applicazioni di intelligenza artificiale che stanno arrivando sul mercato oggi sono destinate a rimanere. Sono piccoli assistenti utili che velocizzano i processi. Forse, presto, saranno in grado di guidare le auto in modo davvero sicuro ed efficiente. O forse no.

Ridisegnare il futuro grazie all’AI

Molte applicazioni di intelligenza artificiale oggi sono veramente impressionanti. Tuttavia, possono essere sviluppate per essere utilizzate in settori critici solo con un grande sforzo e specializzazione. Un esempio è l’Iron Dome, che funziona solo grazie a oltre dieci anni di lavoro di sviluppo. Oggi riconosce i missili con una probabilità del 99% e li abbatte – evitando di colpire oggetti civili – prima che possano causare danni. Per questo motivo, l’IA viene utilizzata principalmente per supportare i sistemi esistenti, piuttosto che operare in modo completamente autonomo. Anche se, come promesso dalla pubblicità, può scrivere e-mail meglio di quanto possiamo o vogliamo fare noi stessi, nessuno oggi sarebbe disposto a delegare completamente la gestione della propria corrispondenza, delle caselle di posta in arrivo e di altri canali di comunicazione a un’IA che si occupa di tutto, limitandosi a informarci solo delle questioni rilevanti con un riepilogo.

Che cosa accadrà a noi in un futuro non troppo lontano? Probabilmente non possiamo saperlo. Succederà davvero? Non lo sappiamo. Quando, forse, quel momento arriverà, i robot si scambieranno messaggi, combatteranno le nostre guerre l’uno contro l’altro e gli attaccanti e difensori informatici basati sull’IA si sfideranno. Quando si renderanno conto che ciò che stanno facendo è inutile, potrebbero chiedersi che tipo di esseri li hanno programmati per farlo. A quel punto, forse si fermeranno, stabiliranno linee di comunicazione, lasceranno la nostra galassia e ci lasceranno indifesi. Almeno, però, avremo ancora il nostro “atto di intelligenza artificiale” e continueremo a regolare quella “IA debole” che non ce l’ha fatta.

Contatto Prova Ora Acquista Torna alla Panoramica

/da
Joseph Lee

Un approccio proattivo alla cybersicurezza diminuisce i costi in caso di fuga di dati

Nel 2024 si stima che il è stato di 9,5 trilioni di dollari. Secondo il un singolo attacco provoca in media 4,88 milioni di dollari di danni economici alla vittima e, mentre le aziende statunitensi subiscono oltre il doppio dei danni rispetto alla media globale, le imprese italiane sono in linea con i valori medi.

In testa alla classifica dei costi, troviamo le misure per , come la risposta all’incidente, la , il ripristino dei sistemi e l’obbligo di segnalazione. Anche le possono far . Nel marzo 2024 l’azienda statunitense Change Healthcare ha che ha comportato perdite stimate intorno a 1,6 miliardi di dollari. E a questi costi potrebbero seguire delle sanzioni normative.

Questo episodio evidenzia quanto sia importante mettere in atto misure di sicurezza proattive sia per evitare che gli attacchi informatici vadano a buon fine, sia per diminuire l’impatto economico se questo dovesse succedere. Secondo i rilevamenti del Ponemon Institute, il 57% dei cyberattacchi avviene per l’assenza di patch di sicurezza. E anche se implementare misure di cybersecurity preventiva contribuisce a diminuire gli attacchi informatici, secondo IBM, gli enti e le aziende che adottano un sistema di vulnerability management proattivo basato sul rischio (RBVM) subiscono costi inferiori in caso di attacco (3,98 milioni di dollari) rispetto a quelli che non adottano queste misure (4,45 milioni di dollari), hanno carenza di personale specializzato (5,36 milioni di dollari) o non sono in regola con le normative di sicurezza informatica (5,05 milioni di dollari).

Quanto è costato a Change Healthcare l’attacco ransomware

A marzo 2024 Change Healthcare ha subito un attacco ransomware che finora ha causato all’azienda circa di danni e per quanto riguarda pagamenti legati all’assicurazione sanitaria. Change Healthcare prevede che l’incidente possa causare una perdita annuale di 1,6 miliardi di dollari. Fondata nel 2007, Change Healthcare è un’importante azienda nel settore delle tecnologie legate al settore sanitario che offre sistemi di gestione del ciclo delle entrate, precisione dei pagamenti e scambio di dati clinici in tutto il mondo. In seguito all’, l’azienda è stata valutata per 8 miliardi di dollari​.

L’inchiesta sulla compliance HIPAA per Change Healthcare

Oltre al grave danno economico, l’Ufficio dei diritti civili del Dipartimento per la salute e i servizi alla persona degli Stati Uniti, l’ente responsabile dell’applicazione dell’HIPAA (Health Insurance Portability and Accountability Act, la legge su portabilità e responsabilità dell’assicurazione sanitaria), ha sull’attacco per capire se Change Healthcare ha violato i requisiti di compliance. Le regole di sicurezza HIPAA prevedono che aziende ed enti coinvolti implementino “pratiche di sicurezza riconosciute” per proteggere le informazioni sanitarie sensibili elettroniche (ePHI) da minacce alla sicurezza ragionevolmente prevedibili.

Le attività continue di vulnerability management sono un tassello essenziale di tutte le architetture di cybersicurezza moderna. Vediamo le cose in positivo: le sanzioni massime per mancata compliance HIPAA hanno un tetto di appena 2 milioni di dollari; davvero poco rispetto al costo totale di risposta e ripristino dopo questo incidente in particolare.

La piattaforma Greenbone Vulnerability Management è in grado di implementare test di compliance personalizzati per ogni framework, come CIS, DISA STIG, HIPAA. Inoltre, Greenbone è certificata per i suoi sistemi di gestione della sicurezza informatica (ISMS) (ISO 27001) e della gestione della qualità (ISO 9000) e da poco anche per la gestione ambientale (ISO-14001).

Contatto Prova Ora Acquista Torna alla Panoramica

/da