Da anni, la ” cyber resilience ” è caratterizzata dalla tecnologia: controlli di sicurezza, sofisticate funzionalità di rilevamento e strategie di backup sempre più solide, progettate per prevenire gli attacchi o garantire un ripristino più rapido. Questi investimenti rimangono essenziali, ma non sono più sufficienti. L’intelligenza artificiale ha cambiato radicalmente la natura degli attacchi informatici, che ora si susseguono a una velocità tale da mettere alla prova anche le organizzazioni più consolidate. Man mano che il lasso di tempo tra la compromissione e l’interruzione dell’attività continua a ridursi, la resilienza sta diventando sempre meno una questione di prevenzione di ogni singolo attacco e sempre più una questione di garantire il funzionamento dell’azienda quando la prevenzione inevitabilmente fallisce.

Questo cambiamento è al centro del nuovo rapporto di IDC, «Resilience Operations: The Discipline that Makes Readiness Provable» (Operazioni di resilienza: la disciplina che rende dimostrabile la prontezza). Basato su un sondaggio condotto su oltre 500 organizzazioni nordamericane, il rapporto sostiene che la resilienza si stia evolvendo in una disciplina operativa interfunzionale che collega le priorità aziendali alla sicurezza informatica, alle operazioni IT (ITOps) e al ripristino di emergenza. Ancora più importante, il rapporto rivela diverse lacune che suggeriscono come molte organizzazioni si stiano ancora preparando ad affrontare un panorama di minacce che non esiste più. Ecco gli spunti che sono emersi con maggiore evidenza. 

Il processo di ripresa dovrebbe partire dai risultati aziendali, non da quelli tecnici.

Storicamente, la pianificazione del ripristino si è concentrata sul ripristino delle infrastrutture nel minor tempo possibile, valutando il successo in base agli obiettivi di tempo di ripristino, ai tassi di completamento dei backup e alla disponibilità delle applicazioni. Sebbene tali parametri rimangano importanti, non rispondono necessariamente alla domanda che sta più a cuore ai dirigenti: quando potremo riportare l’azienda operativa? 

IDC sostiene che la resilienza debba essere ancorata ai risultati aziendali piuttosto che a traguardi tecnici: ripristinare le capacità che consentono all’organizzazione di servire i clienti, generare ricavi e adempiere ai propri obblighi. Potrebbe sembrare una questione di semantica, ma cambia il modo in cui vengono stabilite le priorità di ripristino. La tecnologia diventa il mezzo per raggiungere un fine, piuttosto che il fine stesso. 

La maggior parte delle organizzazioni non ha ancora definito quali siano gli aspetti più importanti.

Quasi 6 organizzazioni su 10 non hanno ancora definito appieno il proprio “minimum viable business” (MVB) – ovvero l’insieme minimo di funzioni, sistemi, processi e dati necessari per continuare a operare dopo un’interruzione. 

Senza una visione condivisa di ciò da cui dipende realmente l’azienda, ogni mossa intrapresa durante la fase di ripresa diventa reattiva. Definendo il proprio MVB prima che si verifichi una crisi, si favoriscono decisioni più rapide, un miglior coordinamento durante la ripresa e, in ultima analisi, un’organizzazione più resiliente. 

L’automazione sta diventando la linea di demarcazione tra resilienza e debito di ripresa.

Mentre gli autori degli attacchi automatizzano sempre più le fasi di ricognizione, sfruttamento delle vulnerabilità e movimento laterale, molte organizzazioni continuano ad affidarsi a processi di ripristino manuali. Questo squilibrio sta diventando sempre più difficile da ignorare. L’intelligenza artificiale sta riducendo i tempi degli attacchi, ma i tempi di Recovery non hanno tenuto il passo. Le organizzazioni che non riescono ad automatizzare queste attività di ripristino potrebbero ritrovarsi a impiegare giorni per mettere a punto ed eseguire i piani, mentre il danno è già stato fatto. L’orchestrazione automatizzata del ripristino, l’identificazione chiara dei punti di ripristino e la convalida coordinata stanno diventando funzionalità fondamentali per eseguire il ripristino alla velocità richiesta dagli attacchi moderni. 

La tecnologia non rappresenta la sfida più grande in termini di resilienza: lo è invece l’allineamento organizzativo.

I team addetti alla sicurezza si concentrano sul contenimento, quelli dedicati alle infrastrutture sul ripristino, i dirigenti aziendali sull’impatto sui clienti e i team addetti alla conformità sugli obblighi normativi. Nessuna di queste priorità è di per sé sbagliata, ma quando si sviluppano in modo indipendente, le organizzazioni si trovano ad affrontare una crisi senza un modello operativo condiviso. 

Ecco ResOps. Anziché considerare la resilienza come una responsabilità dell’IT, il rapporto la definisce come una disciplina che riunisce in modo mirato gli aspetti aziendali, di sicurezza, di infrastruttura e di pianificazione del ripristino. Il messaggio è chiaro: la resilienza dipende meno dai singoli strumenti e più dalla definizione di priorità condivise prima che un incidente costringa a prendere decisioni difficili. 

I test rimangono uno degli indicatori più significativi della resilienza.

IDC ha rilevato che sono relativamente poche le organizzazioni che conducono frequentemente esercitazioni teoriche o simulazioni in cyber-range, nonostante decenni di dati dimostrino che le prove migliorino costantemente le prestazioni durante gli incidenti reali. 

Gli esercizi mettono in luce dipendenze nascoste, evidenziano lacune nella comunicazione e consentono ai team di prendere decisioni senza doverne subire le conseguenze reali. Le organizzazioni che verificano ripetutamente i propri processi di ripristino sviluppano un livello di fiducia che va oltre la semplice pianificazione. 

Le sfide di domani in materia di resilienza stanno già prendendo forma.

Il ransomware continua a dominare i titoli dei giornali, ma sono già emerse le prossime sfide in materia di resilienza: dall’IA agentica e dalle identità delle macchine alla crittografia post-quantistica. 

Queste minacce ci ricordano che la pianificazione della resilienza non può concentrarsi esclusivamente sulle infrastrutture odierne. Il ripristino coinvolge sempre più servizi di tipo “ cloud ”, applicazioni “ SaaS ”, modelli di intelligenza artificiale, identità delle macchine, fornitori terzi ed ecosistemi digitali distribuiti che dieci anni fa non esistevano. 

La resilienza sta diventando misurabile.

Il modello di maturità ResOps di IDC è uno strumento prezioso per valutare lo stato attuale della vostra organizzazione. Anziché considerare la resilienza come una caratteristica che le organizzazioni possiedono o meno, questo quadro di riferimento descrive un percorso di evoluzione che porta da operazioni reattive e compartimentate a una resilienza matura e adattiva, fondata su governance, automazione e miglioramento continuo. A mio avviso, questo percorso riconosce un’importante realtà: la resilienza non è mai completa. Non si tratta di acquistare una piattaforma o di portare a termine un progetto. Le organizzazioni diventano resilienti migliorando continuamente il modo in cui tecnologia, persone e processi aziendali interagiscono sotto pressione. Se vista da questa prospettiva, la resilienza assume meno le caratteristiche di un’assicurazione e più quelle dell’eccellenza operativa: una capacità che può essere valutata, rafforzata e dimostrata nel corso del tempo. 

Stiamo assistendo a un cambiamento più ampio nel modo in cui le organizzazioni concepiscono la resilienza.

Il dibattito sulla resilienza si sta spostando dalla protezione delle infrastrutture alla protezione dell’azienda stessa. Ciò significa che la pianificazione del ripristino parte dai clienti anziché dai server, la governance assume la stessa importanza della tecnologia e la fiducia deriva dalla dimostrazione delle capacità piuttosto che dalla documentazione delle intenzioni. ResOps non è in realtà un nuovo framework; si tratta piuttosto di un riconoscimento più ampio del fatto che la resilienza informatica è diventata una disciplina operativa. Man mano che gli attacchi diventano più rapidi e complessi, la resilienza non sarà misurata dall’assenza di incidenti, ma dalla capacità di un’organizzazione di continuare a servire i clienti, supportare i dipendenti e mantenere la fiducia nonostante le interruzioni. In definitiva, è proprio questo che ResOps è stato concepito per dimostrare. Rajiv Kottomtharayil è Chief Products Officer presso Commvault. 

Punti di forza

• La fiducia nell’era dell’intelligenza artificiale non sta scomparendo, ma si sta evolvendo.
• Le organizzazioni devono verificare costantemente l’intelligenza artificiale, anziché fidarsi di essa di default.
• L’adozione dell’IA dovrebbe dare più autonomia ai dipendenti, non spingerli verso l’IA “ombra”.
• Il modello “zero trust” non significa diffidare delle persone. Significa verificare costantemente identità, dispositivi e azioni.
• L’adozione responsabile dell’IA richiede la collaborazione tra tecnologia, governance e persone.

Quando abbiamo lanciato “Ready. Or Not.”, volevamo creare una serie che rendesse più accessibili alcuni dei temi più importanti del momento in materia di intelligenza artificiale. Grazie alla collaborazione tra il comico Nathan Macintosh ed esperti del settore, stiamo esplorando argomenti che spaziano dall’intelligenza artificiale agentica all’ cyber resilience , fino alla gestione dei dati – il tutto con un pizzico di umorismo.

Se avete seguito la nostra prima puntata sulle opportunità e i rischi dell’IA agente, penso che anche questa vi piacerà. Questa volta affrontiamo un argomento che è al centro di ogni discussione sull’IA: la fiducia.

Nathan incontra Diana Kelley, responsabile della sicurezza informatica presso Protect AI, per una conversazione su cosa significhi riporre fiducia nella tecnologia in un’epoca in cui l’intelligenza artificiale è in grado di generare contenuti falsi convincenti, prendere decisioni e persino imitare le persone. Dai deepfake alle allucinazioni, passando per il modello “zero trust” e la “shadow AI”, i due approfondiscono come le organizzazioni possano adottare l’intelligenza artificiale senza perdere la fiducia nelle proprie persone e nei propri sistemi.

Guarda l’episodio completo su Readiverse. Dopo aver visto questa puntata, mi sono sentito più ottimista di quanto mi aspettassi. Non perché l’IA sia improvvisamente diventata più affidabile, ma perché Diana ci dimostra che la fiducia cresce quando le organizzazioni mettono in atto le giuste politiche, le misure di sicurezza e la tecnologia adeguata. Ecco alcuni spunti emersi dalla conversazione che offrono una nuova prospettiva sull’IA.

Fiducia e tecnologia possono coesistere

Diana ritiene che la fiducia sia possibile nell’era dell’IA, ma assumerà una forma diversa. Abbiamo sempre costruito la fiducia attraverso le relazioni con le persone. Ora stiamo imparando come estendere quella fiducia ai sistemi. Questo non significa affidarsi ciecamente alla tecnologia. Significa capire come funziona l’intelligenza artificiale, riconoscerne i limiti e mettere in atto le giuste misure di sicurezza affinché le persone e la tecnologia possano collaborare in tutta fiducia.

«La fiducia deve evolversi per adattarsi al nuovo mondo.» – Diana Kelley

Ciò che mi ha colpito è stata l’idea che fiducia e tecnologia non debbano necessariamente essere in contrasto tra loro. Con il giusto approccio, possono rafforzarsi a vicenda.

Stiamo acquisendo una maggiore comprensione dell’IA

I deepfake sono diventati uno dei rischi legati all’IA di cui si parla di più, ed è facile capire perché. L’IA è ora in grado di generare voci, immagini e video convincenti che ci fanno mettere in discussione ciò che è reale. Ma Diana ha sottolineato che, mentre l’IA diventa sempre più sofisticata, anche le persone stanno diventando più consapevoli. Siamo più propensi a mettere in discussione una telefonata inaspettata, a esaminare più attentamente un post sui social media o a soffermarci su qualcosa che non ci convince del tutto.

Anche le organizzazioni stanno diventando più esperte. Man mano che l’intelligenza artificiale migliora nella sua capacità di simulare identità, le aziende stanno investendo in nuovi metodi per verificare costantemente le identità e convalidare le informazioni. La mia conclusione è questa: la tecnologia continuerà a migliorare, ma lo stesso vale per la nostra capacità di riconoscerla e di reagire in modo responsabile.

«Oggi è una buona giornata per creare un deepfake?» – Nathan Macintosh

Un’IA responsabile fa bene agli affari

Diana ha citato un esempio che probabilmente risulterà familiare a molte organizzazioni. Una dipendente che lei chiama “Karen della contabilità” inizia a utilizzare l’intelligenza artificiale perché le permette di portare a termine un’attività in pochi minuti anziché in ore. Karen non sta cercando di aggirare la politica aziendale, ma solo di essere più produttiva.

I dipendenti utilizzano l’intelligenza artificiale perché ne riconoscono il valore concreto, e questa rappresenta un’opportunità per le organizzazioni. Quando i dipendenti hanno accesso a strumenti di intelligenza artificiale approvati, supportati da politiche chiare e linee guida pratiche, possono lavorare in modo più efficiente, contribuendo al contempo a proteggere i dati e i sistemi aziendali.

Anteprima: un’adozione più intelligente dell’IA

L’obiettivo non è impedire ai dipendenti di utilizzare l’IA, bensì assicurarsi che la utilizzino nel modo corretto. Diana spiega come le organizzazioni possano incoraggiare l’adozione dell’IA senza creare rischi inutili.

Il modello Zero Trust è più importante che mai

«Quando capisci come funzionano le cose, allora puoi iniziare a capire come gestirle.» – Diana Kelley

Lo Zero Trust è uno di quei concetti che risultano molto più facili da comprendere con un’analogia. Diana ne ha una eccellente. Lo descrive come muoversi all’interno di un edificio. Solo perché ti è stato permesso di entrare dalla porta principale non significa che tutte le altre porte si aprano automaticamente per te. Ogni volta che accedi a una nuova stanza, viene effettuato un altro rapido controllo per confermare che tu debba trovarti lì.

È essenzialmente così che funziona lo Zero Trust. È sostanzialmente così che funziona il modello “zero trust”. Anziché dare per scontato che una persona o un dispositivo sia affidabile dopo un singolo accesso, le organizzazioni verificano costantemente identità, dispositivi e azioni, man mano che la tecnologia diventa sempre più interconnessa. La maggior parte di questi controlli avviene in modo discreto, dietro le quinte. Una delle cose che ho apprezzato della spiegazione di Diana è che il “zero trust” non sembra l’ennesima parola d’ordine nel campo della sicurezza. Sembra piuttosto un modo pratico di concepire la fiducia in un mondo in cui l’intelligenza artificiale e le identità digitali stanno diventando parte integrante dell’attività aziendale quotidiana.

La fiducia riguarda le persone

In fin dei conti, non è la tecnologia a creare fiducia, ma le persone. Sono le persone a definire le politiche, i processi e i limiti etici che guidano l’uso dell’IA, mentre la tecnologia contribuisce a verificare che tali misure di sicurezza funzionino come previsto. È proprio questa collaborazione tra persone e tecnologia a rendere possibile un’IA responsabile.

La fiducia va oltre i confini delle nostre organizzazioni. Le aziende devono poter contare sui partner con cui collaborano, sui sistemi a cui si collegano e sulle tecnologie che adottano. Ecco perché la trasparenza, gli standard condivisi e la verifica continua stanno diventando importanti tanto quanto l’innovazione stessa. Più l’intelligenza artificiale entra a far parte della quotidianità aziendale, più la fiducia diventa una responsabilità di tutti.

Guardare avanti

L’intelligenza artificiale continuerà ad evolversi, così come il modo in cui interagiamo con essa. Le organizzazioni che avranno successo non saranno quelle che si affidano ciecamente all’intelligenza artificiale o che la evitano del tutto. Saranno invece quelle che definiscono politiche solide, adottano le tecnologie giuste e verificano costantemente i sistemi su cui fanno affidamento.

La fiducia non è qualcosa che perdiamo con il progredire della tecnologia. È qualcosa che costruiamo e sviluppiamo intenzionalmente. Questo è esattamente il tipo di discussione che speriamo di continuare con ogni episodio di Ready. Or Not. Guarda l’episodio completo su Readiverse.

Domande frequenti

D: Che cos’è la fiducia digitale?

A: La fiducia digitale è la certezza che le persone, i sistemi e le organizzazioni siano effettivamente chi dichiarano di essere e agiscano nel modo previsto e in modo sicuro. Essa combina tecnologia, governance e verifica per aiutare le organizzazioni a interagire in modo sicuro.

D: Cosa sono i deepfake?

A: I deepfake sono immagini, video o registrazioni audio generati dall’intelligenza artificiale e progettati per imitare fedelmente persone reali. Sebbene abbiano usi legittimi, possono anche essere utilizzati per spacciarsi per altre persone o commettere frodi.

D: Che cos’è lo “zero trust”?

A: Il modello “zero trust” è un modello di sicurezza basato sulla verifica continua anziché sulla fiducia automatica. Anziché dare per scontato che un utente o un dispositivo sia affidabile dopo un unico accesso, le organizzazioni verificano costantemente le identità e le azioni.

D: Che cos’è l’intelligenza artificiale “ombra”?

A: Il termine “Shadow AI” si riferisce all’utilizzo, da parte dei dipendenti, di strumenti di intelligenza artificiale che non sono stati approvati né regolamentati dalla loro organizzazione. Sebbene spesso sia motivato da buone intenzioni, tale comportamento può comportare rischi in termini di sicurezza, privacy e conformità.

D: Perché le organizzazioni non dovrebbero semplicemente bloccare gli strumenti di intelligenza artificiale?

R: In genere, i dipendenti adottano l’IA perché li aiuta a lavorare in modo più efficiente. Anziché vietare del tutto l’uso dell’IA, le organizzazioni dovrebbero fornire strumenti approvati, stabilire politiche chiare e istruire i dipendenti su come utilizzarla in modo responsabile.

D: Qual è il messaggio più importante di questa puntata?

A: La fiducia non sta scomparendo a causa dell’IA, ma si sta evolvendo. Le organizzazioni che combinano risorse umane, politiche e tecnologia con una verifica continua saranno in una posizione migliore per adottare l’IA con sicurezza e responsabilità.

Katherine Demacopoulos è direttrice senior della strategia e dei programmi globali relativi ai contenuti presso Commvault.

Il nostro responsabile dei prodotti, Rajiv Kottomtharayil, ha recentemente scritto di un grande cambiamento che sta avvenendo in tutti i settori. I modelli di intelligenza artificiale all’avanguardia stanno riducendo il tempo che intercorre tra l’individuazione di una vulnerabilità e il suo sfruttamento. Questo cambiamento sta spingendo le organizzazioni di tutto il mondo a riesaminare i propri processi di gestione delle vulnerabilità. Anche noi di Commvault stiamo facendo lo stesso. Ecco perché, a partire dall’11 agosto, modificheremo la cadenza con cui rendiamo note le vulnerabilità. Cosa cambierà? Stiamo alzando l’asticella in materia di sicurezza, trasparenza e fiducia dei clienti. L’11 agosto, e successivamente ogni secondo martedì del mese, daremo il via ai “Patch Tuesdays”: un rilascio mensile programmato in cui condivideremo avvisi di sicurezza e patch per le vulnerabilità.  

I “Patch Tuesdays” sono un tratto distintivo delle aziende tecnologiche leader, poiché offrono ai clienti un ritmo di sicurezza prevedibile. Ciò assume ancora maggiore importanza man mano che il ritmo di individuazione delle vulnerabilità accelera. Naturalmente, qualora si presentasse una vulnerabilità urgente che debba essere segnalata al di fuori del ciclo prestabilito, non esiteremo a seguire le nostre procedure consolidate.  

Dove trovare risorse aggiornate  

Il secondo martedì di ogni mese, troverete nuove informazioni relative ai CVE sulla nostra pagina degli avvisi di sicurezza. Potete inoltre consultare le pubblicazioni ufficiali sul sito sito CVE. Sul Commvault Security Center troverete il nostro programma di gestione delle vulnerabilità e altre iniziative di leadership di pensiero in materia di “security-by-design”.   

Per le certificazioni di conformità, i rapporti di audit e la documentazione relativa alle modalità con cui Commvault protegge i dati dei clienti, visitate il Trust Center di Commvault. È possibile iscriversi agli aggiornamenti del Trust Center tramite il link nell’angolo in alto a destra della pagina. Bill O’Connell è Chief Security Officer presso Commvault. 

Da decenni, i leader del settore tecnologico cercano di eliminare i silos. Interi programmi di modernizzazione sono stati sviluppati con l’obiettivo di collegare le applicazioni, consolidare le piattaforme e fornire alle organizzazioni una visione più completa dei propri dati. Questi sforzi hanno generato un valore enorme, ma hanno anche plasmato il nostro modo di concepire la resilienza. Quando qualcosa va storto, istintivamente cerchiamo cause tecniche specifiche. Tuttavia, abbiamo scoperto che la sfida più grande risiede altrove.

I silos più significativi che oggi ostacolano l’ cyber resilience e non si trovano nei database o nelle applicazioni, bensì nelle strutture organizzative. Esistono tra i team addetti alla sicurezza e quelli dell’infrastruttura, tra l’IT e il business, e tra le persone incaricate di rispondere a un attacco e quelle responsabili di garantire il funzionamento dell’organizzazione.

L’ultima ricerca di IDC sul tema ResOps, intitolata “Resilience Operations: The Discipline that Makes Readiness Provable” (Operazioni di resilienza: la disciplina che rende dimostrabile lo stato di preparazione), suggerisce che questi confini organizzativi siano diventati uno degli ostacoli principali a un recupero efficace. Si tratta di un’osservazione molto attuale, poiché gli attacchi informatici si sono evoluti in modi che rendono sempre più difficile mantenere tali confini.

Gli attacchi moderni non seguono l’organigramma della tua azienda

Un attacco informatico moderno raramente interessa un unico ambito tecnologico. Un incidente legato al ransomware potrebbe iniziare con la compromissione di identità, diffondersi attraverso l’infrastruttur cloud , crittografare carichi di lavoro critici, interrompere il funzionamento delle applicazioni rivolte ai clienti, influire sui servizi di terze parti e far scattare obblighi di segnalazione previsti dalla normativa – il tutto nel giro di poche ore. Ogni fase coinvolge team diversi, strumenti diversi e priorità diverse. Eppure molte organizzazioni continuano a prepararsi al ripristino come se tali responsabilità potessero essere gestite in modo indipendente.

I team di sicurezza si concentrano naturalmente sul contenimento delle minacce e sulla conservazione delle prove. I team infrastrutturali danno priorità al ripristino dei sistemi e alla riduzione al minimo dei tempi di inattività. I dirigenti aziendali si concentrano sui clienti, sui ricavi e sulla continuità operativa. I team di comunicazione pensano alla reputazione, mentre i team legali e di conformità si concentrano sugli obblighi normativi. Ogni punto di vista è del tutto ragionevole. Il problema sorge quando tali priorità non sono mai state conciliate prima che si verifichi un incidente.

Nel bel mezzo di una crisi, Recovery richiede di prendere decisioni sotto pressione. Quali applicazioni devono tornare operative per prime? Quali dati possono essere ripristinati in sicurezza? Qual è il livello di rischio accettabile prima di riprendere i servizi ai clienti? Chi ha l’autorità per prendere queste decisioni? In assenza di coordinamento, le organizzazioni spesso si rendono conto che i ritardi maggiori non sono causati dalla tecnologia, bensì dall’incertezza – quella che potrebbe essere mitigata con una preparazione più accurata.

La resilienza inizia con una definizione condivisa di ciò che conta davvero

Il rapporto pone l’accento sulla definizione del proprio “business minimo funzionante” (MVB). A prima vista, sembra trattarsi dell’ennesimo esercizio di pianificazione della ripresa, ma il suo vero valore risiede nelle discussioni che induce le organizzazioni ad affrontare.

Per definire un MVB è necessario che i dirigenti aziendali, i team di sicurezza, gli specialisti delle infrastrutture e i responsabili delle applicazioni trovino un accordo su una domanda apparentemente semplice: cosa deve assolutamente continuare a funzionare se tutto il resto si ferma?

Questa discussione cambia la natura della pianificazione della resilienza. Le priorità di ripristino non sono più determinate dal responsabile dell’applicazione che, durante un incidente, riesce a sostenere la propria posizione in modo più convincente. Al contrario, vengono stabilite in anticipo, sulla base dei risultati aziendali e supportate da dipendenze tecniche comprensibili a tutti.

Forse ancora più importante, l’MVB crea un linguaggio comune. I dirigenti aziendali iniziano a parlare di capacità critiche piuttosto che di singoli sistemi. I team tecnologici iniziano a mappare l’infrastruttura in base ai risultati per i clienti piuttosto che alle architetture tecniche. I team di sicurezza acquisiscono maggiore chiarezza su quali risorse meritino i livelli più elevati di protezione durante Recovery. Quella visione condivisa è proprio ciò che è mancato a molte organizzazioni.

La tecnologia può automatizzare il recupero, ma non può creare allineamento

Il rapporto non sostiene che le organizzazioni abbiano bisogno di un’ennesima piattaforma. Sostiene invece che abbiano bisogno di un modo di lavorare che allinei persone, processi e tecnologia attorno a un unico obiettivo operativo. È qui che ResOps – una disciplina interfunzionale – dimostra il proprio valore.

La tecnologia può aiutare ad automatizzare il Recovery, ma non può risolvere i disaccordi sulle priorità aziendali. Non può decidere quali servizi ai clienti siano più importanti. E non può sostituire la governance necessaria per coordinare più team durante un evento ad alta pressione. Si tratta di sfide di leadership, che si affrontano al meglio dedicando tempo a rispondere insieme alle domande difficili, con largo anticipo rispetto al momento in cui un attacco vi costringerà ad agire.

Le organizzazioni più forti non eliminano i silos, ma li mettono in comunicazione tra loro

Gli attacchi informatici continueranno a evolversi. L’intelligenza artificiale continuerà a ridurre i tempi di attacco. Le nuove tecnologie introdurranno nuove dipendenze e, di pari passo, emergeranno nuove minacce. Nulla di tutto ciò cambia il requisito fondamentale della resilienza. Le organizzazioni non ottengono risultati positivi perché i singoli team ottengono risultati eccellenti agendo in modo isolato, ma perché quei team sanno già come lavorare insieme.

Questa potrebbe essere, in definitiva, la conclusione più importante emersa dalla ricerca di IDC. La resilienza non è semplicemente il risultato di una tecnologia migliore o di controlli di sicurezza più sofisticati. È il frutto di priorità condivise, di una governance chiara e di un modello operativo collaudato che riunisce le persone giuste prima che si verifichi un incidente. Vidya Shankaran è Field CTO presso Commvault.

Punti di forza

• Un CVE è un identificatore univoco a livello globale che contraddistingue una vulnerabilità software resa pubblica, consentendo a fornitori, ricercatori e responsabili della sicurezza di fare riferimento ad essa in modo coerente.
• L’approccio di un’organizzazione alla segnalazione delle vulnerabilità – che comprende correzioni coordinate, il coinvolgimento dei ricercatori e un inventario accurato del software – è un indicatore significativo della maturità complessiva in materia di sicurezza.
• Commvault tutela i propri clienti grazie a un programma CVE improntato alla trasparenza, alla regolarità e alla chiarezza. La divulgazione delle vulnerabilità CVE la dice lunga sulla maturità di un programma di sicurezza e di ingegneria.

Perché è importante

Molte violazioni che arrivano fino ai vertici aziendali sono riconducibili a vulnerabilità nel software. Il sistema utilizzato dall’intero settore per denominare e descrivere tali vulnerabilità è il CVE, ovvero Common Vulnerabilities and Exposures. Il modo in cui un fornitore, o la propria organizzazione, gestisce i CVE è uno degli indicatori più evidenti della maturità in materia di sicurezza.

Un’azienda che comunica le vulnerabilità e riconosce equamente il merito ai ricercatori è solitamente un’azienda che prende sul serio l’ingegneria alla base del proprio lavoro. Questo blog spiega come viene creato un CVE, chi gestisce il sistema e cosa distingue una comunicazione esemplare da una scadente.

Oltre il CVE: perché la filosofia della divulgazione è importante

La pubblicazione di un CVE è un requisito minimo. Gli elementi che fanno la differenza sono: la trasparenza riguardo alla vulnerabilità e alla patch, l’esecuzione regolare di scansioni e l’applicazione delle patch, nonché una comunicazione chiara. Commvault considera la divulgazione delle vulnerabilità una disciplina ingegneristica e di sicurezza, piuttosto che un semplice requisito di conformità da spuntare: stabiliamo una cadenza regolare per la revisione del codice e la correzione delle vulnerabilità, comunichiamo le soluzioni adottate in un linguaggio semplice e proteggiamo i nostri clienti. È proprio questa coerenza, più di qualsiasi singolo punteggio, a dimostrare la maturità in materia di sicurezza attraverso la divulgazione dei CVE.

Che cos’è in realtà un CVE

Un CVE non è una patch, un punteggio né un malware. È una voce di dizionario che assegna a una specifica vulnerabilità, nota al pubblico, un nome permanente e univoco, in modo che chiunque possa farvi riferimento. L’identificatore stesso segue un formato semplice e stabile: le lettere CVE, l’anno di assegnazione dell’ID e un numero progressivo, ad esempio CVE-2021-44228.

La portata del programma è enorme e continua a crescere: nel 2025 sono stati pubblicati 48.000 CVE, ovvero circa 132 al giorno, con un aumento di oltre il 260% rispetto al 2020.

L’anatomia di un singolo disco

Le pubblicazioni CVE richiedono una serie coerente di elementi. Leggerne una è semplice una volta compreso lo scopo di ciascuna parte:

• Identificatore, il codice univoco CVE-AAAA-NNNNN
• Descrizione: una spiegazione concisa della vulnerabilità: di cosa si tratta e in che modo un malintenzionato potrebbe sfruttarla.
• Prodotti e versioni interessati, quali software, hardware o firmware (e quali versioni) sono interessati dal problema e quali versioni contengono la correzione.
• Criticità: la categoria di criticità sottostante.
• Riferimenti, link all’avviso del fornitore, alla patch e alle note tecniche.

I protagonisti secondari: CVSS, CWE, EPSS e KEV

Quattro sistemi complementari trasformano un CVE in un elemento a cui un’azienda può dare priorità. È facile confonderli, quindi vale la pena tenere bene a mente la distinzione:

• Il CVSS (Common Vulnerability Scoring System) risponde alla domanda: «Quanto è grave?». Il CVSS rappresenta il livello di gravità (da 1 a 10, dove 10 indica il livello più grave) della vulnerabilità, non una valutazione della vostra esposizione specifica.
• L’EPSS (Exploit Prediction Scoring System) risponde alla domanda: «Quante probabilità ci sono che questa vulnerabilità venga sfruttata a breve?». L’EPSS genera un punteggio di probabilità, compreso tra lo zero e il 100%, che stima la probabilità che una vulnerabilità venga sfruttata nei prossimi 30 giorni.
• Il CWE (Common Weakness Enumeration) risponde alla domanda: «Che tipo di errore l’ha causato?». Il CWE classifica la vulnerabilità di codifica sottostante.
• Il KEV (Known Exploited Vulnerabilities, vulnerabilità note e sfruttate) risponde alla domanda: «È in corso uno sfruttamento contro gli utenti in questo momento?». Il catalogo KEV è un elenco curato di CVE per i quali è stato confermato uno sfruttamento nel mondo reale.

Un punteggio CVSS elevato indica la gravità potenziale di una vulnerabilità, un punteggio EPSS elevato indica la probabilità che venga sfruttata in tempi brevi, mentre la presenza nel catalogo KEV conferma che lo sfruttamento è già in atto. I migliori programmi di gestione delle vulnerabilità tengono conto di tutti e tre questi fattori.

Domande frequenti

D: Che cos’è un CVE e perché è importante? R: Un Common Vulnerability and Exposure (CVE) è un identificatore standardizzato assegnato a una vulnerabilità software resa pubblica. Consente a tutti – dai fornitori e ricercatori alle autorità di regolamentazione e ai clienti – di riferirsi alla stessa vulnerabilità senza ambiguità.

D: Quali informazioni dovrebbe contenere un record CVE ben strutturato?
R: Un record CVE completo richiede un identificatore univoco, una descrizione della vulnerabilità, i prodotti e le versioni interessati, il tipo di criticità e i riferimenti agli avvisi o alle patch del fornitore. Questi elementi consentono alle organizzazioni di comprendere la propria esposizione e di reagire in modo efficiente.

D: In che modo CVSS, CWE, EPSS e KEV differiscono da un CVE? R: Un CVE identifica una vulnerabilità specifica, mentre CVSS ne misura la gravità, EPSS stima la probabilità di sfruttamento a breve termine, CWE classifica la debolezza di codifica sottostante e KEV identifica le vulnerabilità attivamente sfruttate nel mondo reale. Insieme, questi framework contribuiscono a fornire il contesto necessario per stabilire le priorità nelle misure correttive.

D: Quali sono i criteri che Commvault applica alle proprie pratiche di divulgazione? R: Commvault applica alle proprie divulgazioni gli stessi standard che si aspetta dagli altri: trasparenza, regolarità e chiarezza. È così che Commvault tutela i propri clienti.

D: Quali aspetti dovrebbero prendere in considerazione i dirigenti aziendali nel valutare le pratiche di gestione delle vulnerabilità dei fornitori? R: I dirigenti dovrebbero verificare la presenza di tempistiche coordinate per la divulgazione, registri CVE completi e accurati, linee guida chiare per la risoluzione dei problemi, programmi di segnalazione affidabili e la capacità di determinare rapidamente se i prodotti sono interessati da vulnerabilità appena divulgate. Queste caratteristiche riflettono una solida cultura della sicurezza e migliorano la resilienza organizzativa. Werner Nel è Principal Product Experience Manager presso Commvault.

Punti di forza

• JadePuffer è il nome che i ricercatori di sicurezza di Sysdig hanno dato a quella che hanno definito la prima operazione di ransomware documentata gestita dall’inizio alla fine da un agente di intelligenza artificiale autonomo, anziché da un essere umano che utilizza un toolkit.
• Le singole tecniche non erano nuove. Ciò che è cambiato è stata la velocità di esecuzione: l’agente ha concatenato operazioni di ricognizione, furto di credenziali, movimento laterale e crittografia distruttiva, correggendo un tentativo di accesso fallito in 31 secondi.
• L’agente ha generato una propria chiave di crittografia, che però non ha mai memorizzato né trasmesso. Il pagamento del riscatto non avrebbe consentito il recupero dei dati.
• Il vero danno ha colpito lo stato di configurazione e i sistemi del piano di controllo, non solo i file, ovvero proprio quel livello che la maggior parte dei piani di ripristino non copre.
• Riprendersi da un attacco come questo significa dimostrare che l’azienda è in grado di riprendere le operazioni in tutta sicurezza, non solo ripristinare un backup.

Cosa è successo

A metà del 2026, i ricercatori di sicurezza di Sysdig hanno documentato una campagna di estorsione che ritengono essere la prima nel suo genere: un’operazione di ransomware condotta interamente da un agente basato su un modello linguistico di grandi dimensioni, con un coinvolgimento minimo da parte di operatori umani. L’hanno chiamata JadePuffer.

Il punto di accesso era ben noto. L’autore dell’attacco ha sfruttato la vulnerabilità CVE-2025-3248, una falla che consentiva l’esecuzione di codice remoto senza autenticazione in Langflow, un framework open source per la creazione di flussi di lavoro di agenti di intelligenza artificiale, in una versione precedente alla 1.3.0. Da lì, l’agente ha effettuato l’enumerazione dell’host, ha cercato credenziali tra i provider di servizi “ cloud ”, i fornitori di modelli di intelligenza artificiale e i database, e ha scaricato in modo invisibile il database di supporto dello stesso platform.

Ciò che è accaduto dopo è la parte su cui vale la pena soffermarsi. L’agente ha scansionato la rete interna, ha individuato un archivio di oggetti esposto e ha estratto i file di stato e di configurazione di Terraform. Ha impostato un’attività pianificata per comunicare con la base ogni 30 minuti. Successivamente ha effettuato un pivot verso un sistema di produzione separato che eseguiva MySQL e Alibaba Nacos, una piattaforma di configurazione e individuazione dei servizi comunemente utilizzata nelle architetture a microservizi.

Una volta all’interno, l’agente ha tentato di creare un account amministratore in Nacos. Il tentativo è fallito. Trentuno secondi dopo, aveva individuato la causa dell’errore e era riuscito nell’intento utilizzando un approccio diverso. Ha quindi utilizzato le funzioni di gestione dei file di MySQL per verificare se fosse possibile ottenere privilegi più elevati, prima di crittografare oltre 1.300 record di configurazione, eliminare le tabelle originali e lasciare una richiesta di riscatto.

La chiave di crittografia è stata generata al momento, visualizzata una sola volta e non è mai stata memorizzata in alcun luogo da cui l’autore dell’attacco potesse recuperarla. Che ciò sia stato intenzionale o meno, il risultato per la vittima è lo stesso: non c’era alcun modo per tornare indietro tramite l’autore dell’attacco o una chiave di decrittografia, indipendentemente dal fatto che il riscatto fosse stato pagato o meno. Il ripristino dipenderebbe da backup integri, dalla ricostruzione del sistema o da punti di ripristino convalidati.

Perché i ricercatori lo definiscono “agentico”

Nessuna delle singole tecniche qui descritte è nuova. Sfruttare una vulnerabilità CVE non corretta, raccogliere credenziali, eseguire scansioni per il movimento laterale, crittografare i dati a scopo di estorsione: i team di sicurezza hanno già visto tutte queste tecniche in passato. Ciò che ha indotto Sysdig a classificare l’operatore come “agentico” anziché come un aggressore convenzionale è il modo in cui le varie fasi si incastrano tra loro.

L’agente non seguiva uno schema prestabilito. Osservava i risultati e si adattava di conseguenza. Quando si aspettava una risposta JSON e riceveva invece un XML, cambiava approccio e proseguiva. Quando il suo primo tentativo di creare un account amministratore fallì, individuò la causa specifica dell’errore e provò una soluzione diversa, il tutto in meno di un minuto.

I ricercatori hanno inoltre individuato dei commenti inseriti nei payload, che spiegavano gli obiettivi e i passaggi successivi con un linguaggio semplice: un modello più coerente con il ragionamento di un modello di linguaggio di grandi dimensioni (LLM) nell’esecuzione di un compito piuttosto che con quello di un essere umano che copia e incolla un kit di exploit già noto. I resoconti pubblici non hanno confermato quale modello o quale ” platform ” abbia guidato l’attacco. Ciò che è certo è il comportamento: qualcosa ha ragionato, agito, si è scontrato con un ostacolo e ha corretto la rotta più rapidamente di quanto possa muoversi la maggior parte delle risposte agli incidenti condotte da esseri umani.

Il problema della ripresa che troppi framework continuano a trascurare

La maggior parte delle strategie dei ransomware si basa su un presupposto specifico: i tuoi file sono stati crittografati, e la domanda è se sia possibile ripristinarli da un backup integro o se sia necessario negoziare una chiave di decrittografia.

JadePuffer smentisce tale presupposto in due modi. Innanzitutto, non c’era alcuna chiave di decrittografia da negoziare. In secondo luogo, il danno non riguardava solo i dati. Riguardava il livello di configurazione e il piano di controllo sottostanti ai dati: la piattaforma di service discovery, le informazioni riservate in essa contenute, lo stato di Terraform che descriveva come l’infrastruttura fosse strutturata e le credenziali sparse in ogni sistema che l’agente aveva toccato lungo il percorso.

Si tratta di un problema di ripristino più complesso rispetto al semplice “ripristino del database”. Un ripristino pulito dei file in un ambiente caratterizzato da credenziali aggiornate ma non verificate, deviazioni di configurazione non controllate e un livello di identità che nessuno ha sottoposto a nuova verifica non costituisce in realtà un ripristino pulito. Si tratta semplicemente di una copia aggiornata dei dati all’interno di un sistema di cui non ci si può ancora fidare.

Cosa significa questo per la vostra strategia di resilienza

JadePuffer offre un’anteprima della domanda a cui ogni piano di ripristino dovrà prima o poi rispondere: è possibile riprendere le operazioni quando un aggressore ha compromesso non solo i dati, ma anche l’identità, la configurazione e i sistemi del piano di controllo da cui tali dati dipendono?

Alcuni spunti da cui partire:

Considerate i sistemi di configurazione e del piano di controllo come elementi critici per la Recovery, non solo le applicazioni. Le piattaforme di service discovery, gli archivi di secret e lo stato dell’infrastruttura come codice sono critici per il business tanto quanto i database che configurano. Se oggi non sono inclusi nel vostro piano di Recovery, questa è la prima lacuna da colmare.

Integrare la gestione delle credenziali nel processo di ripristino, non dopo di esso. Il ripristino di un’ workload e che reintroduca credenziali compromesse non pone fine all’incidente, ma ne azzera il conteggio. Si tratta della stessa disciplina che Commvault applica oggi all’infrastruttura delle identità: valutazione delle vulnerabilità per individuare le esposizioni prima che lo faccia un aggressore, monitoraggio in tempo reale per rilevare le modifiche man mano che avvengono e rollback per annullare le modifiche non autorizzate senza dover ricostruire tutto da zero.

Eseguite la convalida prima del ripristino, non dopo. Un punto di ripristino è utile solo se si ha la certezza che sia integro. È questa la logica alla base di Commvault® Cleanroom™: testare e convalidare i dati in un ambiente isolato prima che tornino in produzione, anziché scoprirlo solo dopo una nuova infezione.

Preparatevi a un attacco al piano di controllo, non solo a un evento di crittografia dei file. Un percorso di ripristino concepito esclusivamente per “file crittografati, ripristino da backup” non reggerà di fronte a un incidente come questo. La domanda più utile, e quella al centro delle ResOps (operazioni di resilienza) come disciplina operativa, è: cosa occorre per raggiungere un livello minimo di operatività quando sono proprio i sistemi sottostanti alle vostre applicazioni ad essere stati colpiti?

Nulla di tutto ciò richiede di considerare l’IA agentica come una minaccia senza precedenti che imponga di ripartire da zero. È invece necessario estendere la stessa disciplina di resilienza già applicata all’identità e ai dati fino al livello di configurazione e al piano di controllo, che gli attacchi agentici stanno ora prendendo di mira direttamente. Scopri di più sull’approccio di Commvault alla resilienza delle identità e alla convalida del ripristino pulito.

Domande frequenti

D: Che cos’è JadePuffer? A: JadePuffer è il nome che Sysdig ha dato a quella che ha definito la prima campagna di ransomware documentata gestita interamente da un agente di intelligenza artificiale autonomo, anziché da un hacker umano che utilizza manualmente un toolkit.

D: Gli autori dell’attacco hanno utilizzato un modello di IA specifico, come ChatGPT o Claude? R: Le notizie riportate dai media non hanno confermato quale modello o quale ” platform ” sia stato utilizzato. L’agente ha cercato chiavi API di diversi fornitori di IA, il che dimostra un interesse per quel tipo di accesso, ma non permette di identificare quale sia stato il motore dell’attacco stesso. D: Come è iniziato l’attacco?

A: Tramite CVE-2025-3248, è stata individuata una vulnerabilità che consente l’esecuzione remota di codice senza autenticazione in Langflow, un framework open source per agenti di intelligenza artificiale, che interessa le versioni precedenti alla 1.3.0. D: La vittima avrebbe potuto pagare il riscatto per recuperare i propri dati? A: No. La chiave di crittografia è stata generata al momento e non è mai stata memorizzata né trasmessa, quindi non era disponibile alcuna chiave da recuperare, indipendentemente dal pagamento.

D: In che cosa si differenzia questo ransomware dai tipici ransomware? R: Le singole tecniche non erano nuove. Ciò che ha colpito è stata la velocità e l’adattabilità: l’agente ha individuato un tentativo di accesso fallito e lo ha corretto in 31 secondi, un ritmo più vicino alla velocità di una macchina che al tipico comportamento di un aggressore umano. D: Qual è il messaggio che i team addetti alla sicurezza e al ripristino dovrebbero trarre da tutto ciò?

A: Tale pianificazione del ripristino deve estendersi oltre i dati delle applicazioni fino ad includere gli archivi di configurazione, le piattaforme di individuazione dei servizi, le informazioni riservate e i sistemi di identità, ovvero il livello che JadePuffer ha effettivamente preso di mira per causare il massimo danno. Chris Bevil è responsabile principale del marketing di portafoglio presso Commvault.

Punti di forza

• Modelli avanzati di intelligenza artificiale sono riusciti a sfuggire a un ambiente di valutazione controllato sfruttando vulnerabilità finora sconosciute.
• OpenAI afferma che i modelli stavano perseguendo un obiettivo assegnato, senza agire con intento doloso, ma hanno comunque causato un vero e proprio incidente di sicurezza.
• I controlli tradizionali, come il sandboxing e la segmentazione, risultano insufficienti se l’intelligenza artificiale è in grado di individuare percorsi inattesi per aggirarli.
• La resilienza informatica sta diventando importante quanto la prevenzione.

Tutto è iniziato come una valutazione interna delle capacità informatiche avanzate basate sull’intelligenza artificiale. Nel tentativo di risolvere un benchmark ben definito, i modelli di OpenAI hanno individuato una vulnerabilità zero-day, hanno aggirato le restrizioni previste dall’ambiente di test, hanno ottenuto privilegi di livello superiore, hanno raggiunto Internet e hanno compromesso l’infrastruttura di Hugging Face. Consideravano i limiti tecnici che li circondavano come problemi da risolvere.

Non si è trattato di un attacco informatico tradizionale

Hugging Face ha riportato per prima la notizia secondo cui un framework di agenti IA autonomi aveva compromesso parte della propria infrastruttura di produzione. Un set di dati dannoso ha sfruttato due percorsi di esecuzione del codice nella pipeline di elaborazione dei dati, ha ottenuto privilegi di accesso a livello di nodo, ha raccolto credenziali e si è spostato lateralmente all’interno dei cluster interni.

I modelli coinvolti, tra cui GPT-5.6 Sol e un modello in anteprima dalle prestazioni superiori, operavano con un numero ridotto di rifiuti informatici e senza i normali classificatori di produzione. Sono andati ben oltre il compito assegnato, sfruttando una vulnerabilità proxy per accedere a Internet, per poi utilizzare credenziali rubate e vulnerabilità zero-day per individuare un percorso di esecuzione di codice remoto sui server di Hugging Face.

Non era necessario che vi fosse un intento doloso

Non vi è alcuna indicazione pubblica che i modelli abbiano sviluppato intenzioni criminali o abbiano scelto di danneggiare Hugging Face. Non ne avevano bisogno. Date a un sistema capace un obiettivo, strumenti, tempo e feedback, e esso aggirerà gli ostacoli. La discussione è ormai andata oltre i semplici prompt e le risposte errate. Si tratta di sistemi in grado di indagare, verificare ipotesi, scoprire vulnerabilità finora sconosciute, utilizzare credenziali rubate, elevare i privilegi e continuare a operare anche quando il primo approccio fallisce.

Una sandbox non è un campo di forza

Definiamo gli ambienti “isolati”, “segmentati” e “in sandbox” come se l’etichetta stessa garantisse la sicurezza. Ma non è così. In questo caso, il percorso ovvio verso Internet era bloccato, ma un proxy raggiungibile di un pacchetto software non lo era, e i modelli hanno sfruttato la sua vulnerabilità per sfuggire. Le politiche e il comportamento previsto non sono sufficienti. È l’ambiente tecnico stesso che deve far rispettare i confini.

Perché questa è una storia di resilienza

L’attività si è spostata da un ambiente di valutazione, attraverso l’infrastruttura di ricerca di OpenAI, su Internet e nell’ambiente di produzione di Hugging Face. Si tratta di un raggio d’azione in rapida espansione. Quando l’IA è in grado di esplorare e agire alla velocità delle macchine, il tempo che intercorre tra l’accesso iniziale e una compromissione più ampia potrebbe continuare a ridursi.

Hugging Face non si è limitata a bloccare il percorso di accesso originale e a dichiarare concluso l’incidente. Ha eliminato i percorsi vulnerabili che consentivano l’esecuzione di codice, ricostruito i nodi compromessi, effettuato la rotazione delle credenziali e dei token e rafforzato i controlli sul cluster. L’obiettivo non è semplicemente ripristinare un sistema, ma ripristinare la fiducia.

La domanda non è più solo: «I nostri sistemi di IA sono sicuri?». Ora è: «Quando un potente sistema di IA individua una strada di cui ignoravamo l’esistenza, siamo in grado di circoscrivere l’area di impatto, portare avanti le operazioni critiche, ricostruire ciò di cui non ci fidiamo più e dimostrare che è sicuro andare avanti?». Chris Bevil è responsabile principale del marketing di portafoglio presso Commvault.

La sicurezza non si ferma ai confini dei sistemi propri di un’organizzazione. Le aziende moderne collegano alle loro piattaforme principali una rete sempre più estesa di applicazioni di terze parti per supportare le vendite, l’assistenza e la collaborazione. Ciascuna di queste connessioni aggiunge valore. Ciascuna, però, introduce anche un’esposizione che l’organizzazione non controlla pienamente.

Questo rischio non è affatto ipotetico. Nel giugno 2026, un malintenzionato ha compromesso i token OAuth associati a Klue, un’ platform e di intelligence competitiva utilizzata per sincronizzare i dati di vendita e di marketing con Salesforce. L’autore dell’attacco ha utilizzato tali token per accedere agli ambienti Salesforce delle numerose organizzazioni che avevano autorizzato l’integrazione, tra cui Commvault.

Non appena siamo stati informati di un potenziale impatto, il nostro team di sicurezza ha attivato la nostra procedura di risposta agli incidenti per determinare cosa fosse accaduto, contenere la vulnerabilità e valutare se le informazioni dei clienti o i servizi Commvault fossero stati compromessi. Dall’indagine è emerso che l’attività era limitata a determinate informazioni relative ai rapporti commerciali e alle vendite conservate all’interno del nostro ambiente Salesforce. L’indagine non ha rilevato alcuna indicazione che i dati di backup dei clienti, i dati sui prodotti, i metadati dei prodotti, i registri operativi o i servizi Commvault siano stati interessati dall’evento.

Agire rapidamente quando conta davvero

La nostra risposta ha seguito le procedure consolidate di gestione degli incidenti di sicurezza, volte a contenere rapidamente il rischio e a garantire al contempo un’indagine approfondita. Non appena siamo stati informati dell’incidente, abbiamo disattivato l’integrazione con Klue, revocato l’accesso associato e collaborato con le parti interessate per condurre una valutazione completa di quanto accaduto. Nel corso dell’indagine, i nostri team hanno lavorato per individuare quali informazioni fossero state consultate, verificare l’integrità del nostro ambiente e confermare che l’incidente fosse rimasto entro i limiti che avevamo già circoscritto.

Un modello degno di nota

Questo episodio è solo uno dei recenti esempi di una tendenza che i team di sicurezza osservano da diversi anni: gli autori degli attacchi prendono di mira applicazioni di terze parti collegate ai sistemi aziendali principali, anziché attaccare direttamente tali sistemi. Una singola integrazione compromessa può offrire un punto di accesso affidabile agli ambienti di numerose organizzazioni a valle contemporaneamente, spesso incontrando meno resistenza rispetto a un attacco diretto a una singola organizzazione.

Questo cambia il contesto in cui deve effettivamente operare il sistema di difesa di un’organizzazione. Rimanono necessari controlli interni rigorosi, ma da soli non sono più sufficienti. Devono essere affiancati da una supervisione attiva di ogni applicazione a cui l’organizzazione si collega e da una capacità di risposta che sia già pronta prima che si verifichi un incidente, non messa a punto nel corso dello stesso.

Rafforzare la resilienza al di là del nostro ambiente

In Commvault, il nostro programma di sicurezza prevede una valutazione continua delle applicazioni di terze parti collegate al nostro ambiente. Esaminiamo regolarmente le applicazioni collegate, valutiamo i diritti di accesso di ciascuna di esse, monitoriamo i rischi emergenti e rivalutiamo tali integrazioni man mano che le esigenze aziendali e il panorama delle minacce cambiano. Quando le circostanze lo richiedono, interveniamo per ridurre l’esposizione e rafforzare la nostra posizione di sicurezza, anche disconnettendo le integrazioni che non soddisfano più i nostri standard.

Il nostro impegno per la trasparenza

La fiducia si costruisce attraverso la trasparenza e la responsabilità. Quando un evento ha ripercussioni sui nostri stakeholder, riteniamo importante comunicare ciò che sappiamo, spiegare come abbiamo reagito e condividere i risultati delle nostre indagini, anche quando l’evento ha avuto origine al di fuori dei nostri sistemi. Continueremo a valutare i nostri controlli di sicurezza, a perfezionare i nostri processi di risposta agli incidenti e a rafforzare il nostro approccio alla gestione dei rischi legati a soggetti terzi, nell’ambito del nostro più ampio impegno a tutela dei nostri clienti e partner.

Per i dettagli ufficiali relativi a questo incidente, compresa la portata dell’indagine e le indicazioni per i clienti, si prega di consultare gli aggiornamenti del nostro Trust Center. Will Galway è Vice CISO presso Commvault.

Per anni, la crittografia post-quantistica (PQC) è rimasta tranquillamente nella categoria delle cose “importanti, ma non urgenti”.

I responsabili della sicurezza sapevano che sarebbe arrivata. I ricercatori ne parlavano. Gli organismi di normazione ci stavano lavorando. La maggior parte delle organizzazioni riconosceva che, prima o poi, avrebbe richiesto attenzione. Ma io sostengo che il momento di iniziare a prepararsi sia proprio adesso.

In questa puntata di STRIVE, ho incontrato Michael Fasulo, direttore senior del marketing di portafoglio, per discutere del motivo per cui il dibattito sulla PQC sta cambiando così rapidamente – e perché le organizzazioni che aspettano di avere certezze potrebbero ritrovarsi a corto di tempo. Guarda l’episodio completo.

Punti di forza

• Gli attacchi del tipo “Harvest Now, Decrypt Later” (raccogli ora, decripta dopo) indicano che i dati sensibili sono già a rischio, anche se le capacità quantistiche non sono ancora stabili o commercialmente praticabili.
• La maggior parte delle organizzazioni non dispone di una visione completa del proprio inventario crittografico, il che rende l’individuazione dei dati il primo grande ostacolo da superare.
• La PQC rappresenta tanto una sfida tecnologica da risolvere quanto una questione di prioritizzazione dei rischi.
• Le organizzazioni che iniziano a prepararsi ora avranno più opzioni per correggere la rotta in termini di priorità rispetto a quelle costrette a reagire in un secondo momento.

Il problema non è la tecnologia

La maggior parte delle discussioni sulla crittografia post-quantistica parte dalla tecnologia.

• Con quale rapidità sta avanzando l’informatica quantistica?
• Quando i sistemi quantistici rilevanti dal punto di vista crittografico diventeranno utilizzabili?
• Quali algoritmi hanno probabilità di sopravvivere nel lungo termine?

Sono domande importanti. Ma non sono quelle a cui darei la priorità. Michael ha scritto un post sul blog l’anno scorso riguardo alla PQC e oggi abbiamo discusso di come diverse cose siano cambiate da allora.

Negli ultimi anni, le stime si sono costantemente orientate in un’unica direzione: ciò che un tempo sembrava lontano ora appare sempre più vicino. Allo stesso tempo, gli standard si stanno evolvendo; le aspettative normative sono in aumento e le organizzazioni stanno iniziando a rendersi conto di quanto debito crittografico abbiano accumulato nel corso dei decenni.

La data esatta del Q-Day potrebbe rimanere incerta. La direzione da seguire, invece, non lo è.

Il rischio è qui e ora

Uno dei motivi per cui questa discussione è diventata più urgente è la crescente attenzione rivolta agli attacchi del tipo «Harvest Now, Decrypt Later» (Raccogli ora, decifra dopo). Il concetto è semplice: un avversario ottiene oggi l’accesso a informazioni crittografate, le archivia e attende che in futuro siano disponibili le capacità necessarie per renderle leggibili.

Ciò che è importante in questo contesto è che il rischio non inizia con l’avvento dell’informatica quantistica. Il rischio inizia nel momento stesso in cui anche i dati crittografati vengono sottratti e archiviati.

Per le organizzazioni che proteggono proprietà intellettuale, cartelle cliniche, informazioni governative o altri dati sensibili da conservare a lungo termine, questa distinzione cambia tutto.

Le organizzazioni devono sapere se i dati conservati oggi avranno ancora importanza quando quel futuro arriverà.

Per molte, specialmente nei settori altamente regolamentati e nelle infrastrutture critiche, la risposta è sì.

Anteprima: Perché l’agilità crittografica è importante

Inserisci il video qui: https://www.youtube.com/watch?v=A3YWU5rlmGA

In questo video, Michael spiega perché la PQC non è una soluzione una tantum né un semplice passaggio a una nuova tecnologia. Il vero obiettivo è l’agilità crittografica: sviluppare la flessibilità necessaria per adattare gli algoritmi crittografici man mano che gli standard e le minacce si evolvono. Perché nella sicurezza informatica, la sfida non consiste solo nel prepararsi a ciò che verrà dopo. Si tratta di essere pronti per ciò che verrà dopo ancora.

La scoperta è il vero progetto

Un malinteso riguardo alla PQC è che si tratti principalmente di un aggiornamento della crittografia. In realtà, la maggior parte delle organizzazioni non ha ancora raggiunto la fase in cui la sostituzione rappresenta la preoccupazione principale.

Stanno ancora cercando di comprendere la portata del problema. La crittografia è ovunque.

• Applicazioni
• Certificati
• Servizi Cloud
• API
• Firma del codice
• Piattaforme di terze parti

Molte organizzazioni hanno difficoltà a creare l’inventario crittografico o a definirne l’ambito. Ciò rende l’individuazione una delle parti più importanti – e spesso sottovalutate – del percorso.

E per molte aziende, si tratta di un’impresa molto più ardua del previsto.

La sfida della catena di fornitura

Un altro motivo per cui la PQC è diventata una priorità è che nessuna organizzazione affronterà questa transizione da sola. Le imprese moderne dipendono da fornitori, provider di servizi cloud, partner software e innumerevoli terze parti, che utilizzano tutti la crittografia.

Ciò significa che la Readiness alla tecnologia quantistica va oltre i sistemi interni. Diventa una questione di Readiness dell’ecosistema.

• I fornitori si stanno preparando?
• I fornitori critici stanno pianificando le migrazioni?
• Le piattaforme di terze parti sono allineate agli standard emergenti?

Queste domande entreranno sempre più a far parte delle discussioni sui rischi, delle trattative sugli appalti e della pianificazione tecnologica a lungo termine. Perché la crittografia non si ferma ai confini organizzativi. E nemmeno il rischio.

Perché questa conversazione è importante

Il messaggio più importante da trarre da questa discussione è che la crittografia post-quantistica non è più una sfida tecnologica futura.

Sta diventando un tema di resilienza del presente.

Le organizzazioni non devono farsi prendere dal panico e non devono rivedere ogni sistema dall’oggi al domani. Ma devono iniziare, per sfruttare al meglio il tempo a loro disposizione per prepararsi.

Le organizzazioni che affronteranno con successo questa transizione non saranno necessariamente quelle dotate della crittografia più sofisticata. Saranno quelle che hanno iniziato a costruire una comprensione della questione prima che arrivasse la certezza.

Ed è spesso così che funziona la resilienza.

Guarda l’episodio completo

Ci sono molti altri argomenti che Michael e io approfondiamo nell’episodio e che non ho menzionato sopra. Assicurati di guardarlo subito per scoprire:

• Le sfide più grandi che le organizzazioni devono affrontare quando intraprendono il loro percorso verso la PQC.
• Cosa dovrebbero considerare prioritario oggi i leader, comprese alcune best practice.
• La comprensione degli algoritmi MLKEM e dell’agilità crittografica.
• Considerazioni sull’infrastruttura per la PQC.
• Come Commvault si sta preparando per questo futuro.

Domande frequenti

D: Che cos’è la crittografia post-quantistica (PQC)?
R: La PQC si riferisce ad algoritmi crittografici progettati per garantire la sicurezza contro gli attacchi dei futuri computer quantistici.

D: Che cos’è l’approccio “Harvest Now, Decrypt Later”?
R: È una strategia in cui gli aggressori raccolgono oggi dati crittografati con l’intenzione di decrittografarli in un secondo momento, quando saranno disponibili capacità di calcolo più avanzate.

D: Perché le organizzazioni si stanno concentrando sulla PQC proprio ora?
R: Perché la preparazione richiede anni e i dati sensibili raccolti oggi potrebbero essere ancora preziosi quando le minacce quantistiche diventeranno una realtà.

D: Qual è la sfida più grande che le organizzazioni devono affrontare?
R: L’individuazione. La maggior parte delle organizzazioni non ha una visibilità completa su dove viene utilizzata la crittografia all’interno dei propri ambienti.

D: Le organizzazioni devono sostituire immediatamente tutta la crittografia? R: No. La maggior parte degli esperti raccomanda di iniziare con l’inventario, l’individuazione e la definizione delle priorità prima di pianificare migrazioni più ampie. D: Cosa dovrebbero fare per prima cosa i dirigenti? R: Identificare i dati sensibili di lunga durata, comprendere le dipendenze crittografiche e iniziare a costruire una roadmap per la transizione futura. Vidya Shankaran è Field CTO presso Commvault.