Tag Archivio per: Vulnerability Management

Greenbone AG

Nuove interessanti funzionalità per le Enterprise Appliance di Greenbone

Siamo lieti di annunciare il lancio di importanti aggiornamenti al Greenbone Operating System (GOS), il software alla base delle nostre appliance aziendali fisiche e virtuali. Questi aggiornamenti introducono nuove funzionalità front-end per migliorare la gestione delle vulnerabilità aziendali e allo stesso tempo potenziano le prestazioni nel back-end. La versione 24.10 del GOS riflette l’impegno di Greenbone nel promuovere buone pratiche di sicurezza informatica, permettendo alle organizzazioni di identificare e risolvere rapidamente le vulnerabilità.

In questo articolo presentiamo le nuove funzionalità e i miglioramenti che rendono le nostre appliance aziendali ancora più efficaci nella gestione delle esposizioni e della conformità alla sicurezza informatica.

Tutte le nuove funzionalità di GOS 24.10

Greenbone Security Assistant (GSA) rende la sicurezza informatica un argomento tangibile per i responsabili IT. La rinnovata interfaccia web GSA presenta un design moderno e minimalista che privilegia l’usabilità, mantenendo l’accessibilità alle potenti funzionalità di Greenbone. Questo restyling estetico è solo l’inizio: sono previsti cambiamenti più sostanziali che trasformeranno ulteriormente l’esperienza d’uso.

Finestra di visualizzazione del nuovo report di audit di conformità

La cybersecurity compliance sta assumendo un ruolo sempre più centrale. Le recenti normative UE come il Digital Operational Resilience Act (DORA), la Network and Information Security Directive 2 (NIS2) e il Cyber Resilience Act (CRA) impongono alle organizzazioni di implementare misure più proattive per salvaguardare la propria infrastruttura digitale. Altri fattori come l’adozione di assicurazioni specifiche per la cybersecurity, l’aumento della richiesta di verifiche esterne indipendenti e una responsabilità più elevata nei confronti dei clienti riguardo la protezione dei dati, stanno inducendo le organizzazioni a riconsiderare e potenziare i propri approcci alla gestione e al monitoraggio della sicurezza informatica.

L’aggiornamento GOS 24.10 introduce una nuova modalità di visualizzazione focalizzata sulla compliance, progettata per migliorare la comprensione dell’allineamento normativo e delle politiche. L’interfaccia utente rinnovata offre una migliore visibilità dei rischi per la sicurezza informatica, favorendo l’allineamento con gli obiettivi di governance IT. Questa vista include report di audit di conformità, nuove visualizzazioni della dashboard e opzioni di filtro avanzate. Le funzionalità permettono di separare efficacemente i dati relativi alla conformità dai report di scansione standard. Inoltre, i report di audit Delta mettono in evidenza i progressi nella conformità attraverso indicatori visivi e suggerimenti, facilitando l’identificazione delle aree di miglioramento.

Il supporto EPSS aggiunge la prioritizzazione basata sull’intelligenza artificiale

Con il costante aumento dei nuovi CVE (Common Vulnerabilities and Exposures), diventa essenziale stabilire delle priorità tra le vulnerabilità per focalizzarsi sulle minacce più critiche. L’Exploit Prediction Scoring System (EPSS) è un sistema di valutazione basato sull’intelligenza artificiale in grado di calcolare la probabilità che un CVE venga effettivamente sfruttato. Questo sistema utilizza il machine learning (ML) per analizzare dati storici e prevedere quali nuovi CVE hanno maggiori probabilità di essere oggetto di attacchi attivi.

I dati EPSS sono ora parte integrante delle nostre appliance aziendali. Le probabilità di sfruttamento, regolarmente aggiornate per ogni CVE attivo, sono ora disponibili nella piattaforma Greenbone. Gli amministratori possono utilizzare punteggi e percentili di probabilità di exploit aggiornati, in aggiunta alla tradizionale valutazione della gravità CVSS. Questo consente loro di concentrarsi sulle vulnerabilità più critiche e urgenti nelle loro operazioni di sicurezza.

Funzionalità di esportazione di report CSV e JSON più flessibili

Greenbone ha sempre adottato un approccio incentrato sulla semplicità e sulla flessibilità, permettendo alle sue soluzioni di adattarsi a una vasta gamma di esigenze operative specifiche. La versione GOS 24.10 introduce una nuova funzionalità: l’esportazione dei report in formato JSON. Inoltre, gli utenti hanno ora la possibilità di personalizzare i campi nei report esportati in formato CSV e JSON. Questa caratteristica consente di adattare i report direttamente all’interno di Greenbone, permettendo di soddisfare con maggiore precisione i requisiti specifici dei report e di focalizzarsi sugli elementi essenziali per l’analisi, la conformità o il processo decisionale.

Ulteriori ottimizzazioni nel backend

Per migliorare la flessibilità e l’accuratezza nell’identificazione delle vulnerabilità, Greenbone ha implementato diverse ottimizzazioni del back-end, focalizzandosi sulla gestione del CPE (Common Platform Enumeration) e dei feed. Ecco una panoramica delle novità introdotte:

  • Il back-end è ora in grado di convertire le stringhe CPEv2.3 in URI CPEv2.2, conservando entrambe le versioni per garantire una corrispondenza più affidabile dei prodotti interessati. Futuri sviluppi potrebbero includere un sistema di corrispondenza avanzato e in tempo reale, aumentando ulteriormente la precisione nella valutazione delle vulnerabilità.
  • Le appliance aziendali Greenbone hanno introdotto il supporto per feed CVE, CPE, EPSS e CERT basati su JSON, oltre alla compressione dei dati tramite gzip.

Indice

Di recente, Greenbone ha rilasciato una serie di aggiornamenti importanti per le sue Enterprise Appliances, introducendo diverse nuove funzionalità e miglioramenti. Gli aggiornamenti introducono un’interfaccia web GSA modernizzata, una visualizzazione dei report di audit incentrata sulla conformità per una migliore visibilità e funzionalità avanzate di esportazione CSV e JSON che offrono agli utenti il controllo sui dati dei report Inoltre, abbiamo aggiunto EPS basati sull’intelligenza artificiale alle opzioni disponibili per la prioritizzazione del rischio di vulnerabilità. Infine, le ottimizzazioni del back-end garantiscono una perfetta compatibilità con i nuovi formati CPE e i feed basati su JSON. Insieme, queste funzionalità si aggiungono alle capacità di gestione delle vulnerabilità adattabili di Greenbone, consentendo alle organizzazioni di stare al passo con le minacce emergenti con il rilevamento e la definizione delle priorità delle vulnerabilità leader del settore.

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

Quattro esperti discutono in un panel della Conferenza di Potsdam sulla sicurezza informatica nazionale 2024 presso l'Hasso-Plattner-Institut delle opportunità e dei rischi dell'intelligenza artificiale nella cybersicurezza.
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, interviene alla Conferenza di Potsdam sulla sicurezza informatica nazionale 2024 presso l’Hasso-Plattner-Institut, parlando delle opportunità e dei rischi dell’intelligenza artificiale nella cybersicurezza.

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